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Preface 



This document is one of a series of specifications which describe Phase V of the Digital Net- 
work Architecture. Other DNA Phase V specifications may be obtained by ordering one or more 
of the following documentation kits: 

DIGITAL NETWORK ARCHITECTURE (PHASE V) DOCUMENTATION KIT#1 

Order No. EK-DNAP1-DK-001 includes: 



Digital Network Architecture (Phase V) General Description, No. EK-DNAPV- 
GD 



Digital Network Architecture (Phase V) Network Services Protocol Functional 
Specification, No. EK-DNA15-FS-001 

Digital Network Architecture (Phase V) Open Systems Interconnect Transport 
Functional Specification, No. EK-DNA12-FS-001 

Digital Network Architecture (Phase V) X.25 Access Functional Specification, 
No. EK-DNA17-FS-001 



DIGITAL NETWORK ARCHITECTURE (PHASE V) DOCUMENTATION KIT #2 

Order No. EK-DNAP2-DK-001 includes: 



Digital Network Architecture (Phase V) Session Control Functional Specifica- 
tion, No. EK-DNA07-FS-001 



Digital Network Architecture (Phase V) Naming Service Functional Specifica- 
tion, No. EK-DNANS-FS-002 

Digital Network Architecture (Phase V) Network Routing Layer Functional 
Specification, No. EK-DNA03-FS-001 

Digital Network Architecture (Phase V) Unique Identifier Functional Specifica- 
tion, No. EK-DNA16-FS-001 



Digital Network Architecture (Phase V) Time Service Functional Specification, 
No. EK-DNA04-FS-001 



DIGITAL NETWORK ARCHITECTURE (PHASE V) DOCUMENTATION KIT #3 

Order No. EK-DNAP3-DK-001 includes: 



Digital Network Architecture (Phase V) High-Level Data Link Control Func- 
tional Specification, No. EK-DNA08-FS-001 

Digital Network Architecture (Phase V) Carrier Sense Multiple Access with Col- 
lision Detection Functional Specification, No. EK-DNA13-FS-001 

Digital Network Architecture (Phase V) Digital Data Communications Message 
Protocol Functional Specification, No. EK-DNA14-FS-001 

Digital Network Architecture (Phase V) Modem Connect Functional Specifica- 
tion, No. EK-DNA10-FS-001 



Digital Network Architecture (Phase V) LAN Node Product Functional Specifi- 
cation, No. EK-DNA06-FS-001 
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DIGITAL NETWORK ARCHITECTURE (PHASE V) DOCUMENTATION KIT #4 

Order no. EK-DNAP4-DK-001 includes: 



Enterprise Management Architecture (EMA) Entity Model Functional Specifica- 
tion, No. EK-EM AEM-FS -002 

Digital Network Architecture (Phase V) Common Management Information Pro- 
tocol Functional Specification, No. EK-DNAO 1 -FS-00 1 

Digital Network Architecture (Phase V) Event Logging Functional Specification, 
No. EK-DNA09-FS-001 



Digital Network Architecture (Phase V) Maintenance Operations Protocol Func- 
tional Specification, No. EK-DNA 1 1 -FS-00 1 

Digital Network Architecture (Phase V) Network Control Language Functional 
Specification, No. EK-DNA05-FS-001 

Digital Network Architecture (Phase V) Network Management Functional Speci- 
fication, No. EK-DNA02-FS-001 
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Chapter 1 



Introduction 



Certain maintenance functions need to be performed remotely at a low level in the overall 
network architecture. These are functions that cannot depend on high level software being op- 
erational in the node (system) being maintained. 

In the context of this specification, low level implies direct usage of data link services. High 
level means such network functions as routing and end-to-end, virtual circuit type protocols, 
both of which are also users of data link services. This specification assumes that only a mini- 
mal level of data link services are available to support maintenance operations, and that these 
maintenance operations provide a base on which any higher level functions can be built. 

This document describes the structure, functions, interfaces, and protocols needed for low 
level maintenance. DNA is the model on which DECnet implementations are based. A DECnet 
network is a family of software modules, data bases, and hardware components used to tie 
DIGITAL systems together for resource sharing, distributed computation or remote system 
communication. 

This document incorporates the support of the new data links such as HDLC data link, 
CSMA/CD (IEEE 802.3) data link, and FDDI (ANSI X3. 139-1987) data link. The term Local 
Area Network (LAN) used throughout this document applies to all Ethernet data link, 
CSMA/CD data link, and FDDI data links. 

This document assumes that the reader is familiar with computer communications and 
DECnet. The primary audience consists of those who implement DECnet systems or other sys- 
tems under different architectures, but requiring the same functions. The following are the 
relevant documents (refer to the Preface for the order numbers): 

• Digital Network Architecture (Phase V) Digital Data Communications Message Protocol 
Functional Specification 

• Digital Network Architecture (Phase V) High-Level Data Link Control Functional 
Specification 

• Digital Network Architecture (Phase V) Carrier Sense Multiple Access with Collision 
Detection Functional Specification 

• Digital Network Architecture (Phase V) FDDI Data Link Architecture Specification, (to 
be published) 

• Digital Network Architecture (Phase V) Network Management Functional Specification 
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• Digital Network Architecture (Phase V) Common Management Information Protocol 
Functional Specification 

• Digital Network Architecture (Phase V) IAN Node Product Functional Specification 

• Enterprise Management Architecture (EMA) Entity Model Functional Specification 

• Digital Network Architecture (Phase V) Event logging Functional Specification 

• Digital Network Architecture (Phase V) Naming Service Functional Specification 

• Digital Network Architecture (Phase V) Unique Identifier Functional Specification 

• Digital Network Architecture (Phase V) Time Service Functional Specification 
The relevant National and International Standards are: 

• IEEE Standard 802: Overview and Architecture. 

• IEEE Standard 802.1 (Part B) : Addressing, Internetworking, and Network Manage- 
ment. 

• IEEE Standard 802.2 : IEEE Standards for Local Area Networks: Logical Link Control, 
ANSI/IEEE Std 802.2-1985, ISO 8802-2. 

• IEEE Standard 802.3 : Carrier Sense Multiple Access with Collision Detect (CSMA/CD), 
ANSI/IEEE Std 802.3-1985 ISO 8802-3. 

• ANSI Standard X3. 139-1987 : Fiber-distributed data interface (FDDI) — token ring 
media access control (MAC). 

• ANSI X3T9/92-037, Rev 7.1 : Fiber-distributed data interface (FDDI) — Station Man- 
agement (SMT). 

1.1 Functional Description 

Low level maintenance functions are divided into three categories. Operation within any 
category depends on the operability of at least part of the preceding category. The categories 
are: 

• Communications test 

• System console 

• System load/dump 

Each of these functions can be viewed either from the active or passive end. The active end 
is the one that is driving the maintenance function and the passive end is the one that is re- 
sponding. 

Communications test determines if the data link communications path is operative. 
System console provides low level access to a system for the functions of: 

• Identify 

• Read data link 
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• Boot system 

• Console carrier 

The console carrier is a general purpose console input/output channel. It provides a common 
communication mechanism to allow remote access regardless of console command specifics. 

System load/dump copies the contents of processor memory to or from a remote system. 

Throughout this document, the term boot is used to mean the process of causing a system to 
initialize itself. Initialization may include loading system memory. A boot command is a cause. 
The term load is used to mean the process of transferring a system image into processor mem- 
ory from some source. This is one potential effect of a boot command. The source of major in- 
terest in this specification is a remote system, accessed via a communication channel. 



1.2 Design Scope 

The low level maintenance operations require certain characteristics to be present, attempt 
to meet certain goals, and lack some features that are not within the scope of the design. 

1.2.1 Requirements 

The maintenance operation architecture must have the following characteristics: 

• The communications test function, system console functions, and system load/dump 
function previously mentioned must be included in the design. 

• Active and passive sides of maintenance operations can be implemented and used inde- 
pendently. 

• Effects of errors (such as operator errors, protocol errors, and hardware errors) are 
minimized, always leaving a system in a well defined state. 

• On CSMA/CD data link, the LAN Loop Test Protocol must be compatible with the inter- 
company standard Ethernet Loopback Protocol as specified in the DEC STD 134-0 
(Digital CSMA/CD (Ethernet) Local Area Network Specification) 

• Implementations may select subsets of functions based on particular product need. The 
required subsets of functions are defined in the LAN Node Product Architecture Specifi- 
cation. 

1.2.2 Goals 

The maintenance operation design tries to have the following characteristics: 

• Functions and protocols are compatible with the DNA Maintenance Operation Protocol 
(MOP) version V3. 1.0. 

• Algorithms, particularly those found in memory-only systems, are processing and mem- 
ory efficient. Communications efficiency is a secondary goal. In the specific case of 
down-line load and up-line dump, overall speed of operation is an important goal. 

• Extensible to accommodate newly developed functions or modification of current func- 
tions. 

• Operates independently of the underlying communication mechanism (e.g., DDCMP, 
Ethernet, CSMA/CD, HDLC, etc.). 
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• No complex algorithms or data bases. Minimal state kept in the smallest systems. 

1.2.3 Non-goals 

The maintenance operation design does not try to have the following characteristics: 

• Isolation of components that have failed in a failing system. 

• System security in the low level maintenance functions. 
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Models 



This chapter describes the relationship of the low level maintenance operations to other net- 
work layers and modules. Although this specification primarily relates the maintenance opera- 
tions to DNA, the same relationships can also be applied within other network architectures, 
such as the DIGITAL System Communication Architecture. 

2.1 Relationship to DIGITAL Network Architecture 

The maintenance operations reside in the DNA Network Management Layer. They are di- 
rect users of the DNA Data Link Layer. The other DNA layers are not required in the support 
of the low level maintenance operations unless such services as remote file access are to be 
used. 

DNA is a layered structure. Modules in each layer perform distinct functions. Modules 
within a single DNA layer (but typically in different computer systems) communicate using spe- 
cific protocols. Modules in different layers (but typically in the same computer system) inter- 
face using subroutine calls or a system-dependent method. In this document interfaces are de- 
scribed in terms of calls to subroutines. 

The diagram in Figure 1 below shows the overall layering of DNA. A later diagram (Figure 
2) shows the simplified model that is applicable to the low level maintenance operations. 



6 



Models 



User modules 



r> etworh Management modules 



Network Application modules 



Session Control modules 



Transport modules 



Network layer modules 



Data Link modules 



Physical Link modules 



Figure 1 : DNA layer model 
Note: 

Horizontal arrows show direct access for control and observation of parameters, 
counters, etc. Vertical arrows show interfaces between layers for normal user 
operations such as file access, down-line load, and logical link usage. 

Each layer in DNA consists of functional modules and protocols. Generally, modules use the 
services of the next lower layer. In this document, the service relationship is demonstrated in 
the way the interfaces are modeled, as calls to subroutines. Note that the Network Manage- 
ment Layer interfaces directly with each of the lower layers. Also, the layers above Session 
Control interface directly with it. For this reason the upper three layers are sometimes referred 
to as the "end user". 



Modules of the same type in the same layer communicate with each other to provide their 
services. The rules governing this communication and the messages required constitute the 
protocol for those modules. Messages are typically exchanged between equivalent modules in 
different nodes. However, equivalent modules within a single node can also exchange mes- 
sages. 



A brief description of each layer follows in order from the highest to the lowest layer: 



2. 2: Simplified Network Model 
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User Layer. The highest layer, the User Layer supports user services and programs. 
Programs such as the Network Control Program, which interfaces with the Network 
Management Layer, and file transfer programs, which interface with the Network Ap- 
plication Layer, reside in the User Layer. 

Network Management Layer. The Network Management Layer is the only one that has 
direct access to each lower layer for control purposes. Modules in this layer provide 
user control over and access to network parameters and counters. These modules also 
perform up-line dumping, down-line loading, and testing functions. 

Network Application Layer. Modules in the Network Application Layer support net- 
work functions, such as remote file access and file transfer, used by the User and Net- 
work Management Layers. 

Session Control Layer. The Session Control defines the system-dependent aspects of 
logical link communication, which allows messages to be sent from one node to another 
in a network. Session Control functions include name-to-address translation, process 
addressing, and, in some systems, process activation and access control. 

Transport Layer. The Transport Layer defines the system-independent aspects of logi- 
cal link communication. 

Network Routing Layer. Modules in the Network Routing Layer route messages, called 
packets, between source and destination nodes. 

Data Link Layer. The Data Link Layer defines the protocol concerning data integrity 
and physical channel management. 

Physical Link Layer. The Physical Link Layer encompasses a part of the device driver 
for each communications device plus the communications hardware itself. The hard- 
ware includes interface devices, modems, and the communication lines. 



2.2 Simplified Network Model 



The diagram in Figure 2 shows a simplified relationship of the maintenance operations to 
the rest of the network architecture. 



User 










Maintenance Operations 



User layer 




DDCMP 





HDLC 




LAPB 






Network 

Management 

Layer 

Data Link Layer 



FDDI 



Figure 2: Simplified network model 
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2.3 Low Level Maintenance Operation Model 

The diagram in Figure 3 shows the components within the maintenance operation module. 



User 



Test/Query 
Requester 



Console 
Requester 



Console 
Server 



^ Dump/Load 
Server 



Dump/Load 
Requester 



Loop 
Requester 




Data Link 



Figure 3: MOP components 

Requesters are the processes responsible for initiation of maintenance operations. This can 
be done either at higher level user request, or because of information obtained from a lower 
level. Requesters are the active side of a maintenance operation. 

Servers are the processes that respond to maintenance requesters. They are the passive side 
of a maintenance operation. Servers should not try to do more than they are capable of. For 
example, it is not acceptable to always volunteer to load every system that requests it and then 
take too long to get done because the local resources are overextended. The diagram shows 
servers and requesters as separate to represent their functional independence. In an imple- 
mentation that supports multiple servers and/or requesters that use the same protocol type, 
they may have to be more closely coupled so that messages received through the data link are 
properly demultiplexed. Also, servers and requesters that allow multiple users must further 
demultiplex messages to the proper user processes. 

The Client Data Base contains default information that the Dump/Load Server, Loop Re- 
quester, Console Requester, and Test/Query Requester use to fill in necessary values in incom- 
plete requests. 



Lines to the top of processes indicate flow of the control data that initiates processing. Lines 
to the side indicate Network Management control. The dashed lines indicate data base access. 
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The operation of the Maintenance Operations components may be monitored and controlled 
using DNA Network Management. There is a single Module entity, called MOP. It has subor- 
dinate entities which define the database of MOP clients, and the Data Link circuits to be used. 
Figure 4 shows the complete entity structure of MOP. 



MOP 




Figure 4: MOP entity structure 



3.1 Client subentity 

The Client subentity is used to store default parameters for the Dump/Load Server, Console 
Requester, Loop Requester, and Test/Query requester. When a Load, Boot, Loop, Test, or 
Query directive is received, any required parameters not supplied with the directive are ob- 
tained from the corresponding characteristics of a Client subentity, if one is specified in the di- 
rective. Similarly, when a request for Dump or Load service is received by the Dump/Load 
Server component from a Data Link, any parameters required to complete the request but not 
supplied in the received message are obtained from the characteristics of a Client subentity. In 
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this case, the Client subentity to be used is determined by the Circuit and (for LAN circuits) the 
Data Link source address or the Device Type from the received request message. 

The set of Client subentities forms the "Client Database". A lookup in this Database consists 
of a search through the set of Client subentities for one that has the specified name, or the 
specified Circuit and (if applicable) LAN Address and/or Device Type. A LAN Address match 
takes precedence over a Device Type match; apart from that, the result of a search when more 
than one Client subentity matches the specified value is undefined. 

3.2 Circuit subentity 

The Circuit subentity describes a Data Link circuit to be used by MOP. For each defined 
Circuit subentity, MOP will use the specified Link Name attribute to open a port in the appro- 
priate Data Link module. Thus, each Circuit subentity of MOP corresponds to a Data Link cir- 
cuit on which MOP services are available. Another Circuit characteristic defines which of the 
possible MOP services are enabled. 

3.2.1 Operation subentity 

The Operation subentity is created dynamically by the MOP components to allow manage- 
ment to observe the state of MOP operations that are in progress. 

3.2.2 Station subentity 

The Station subentity is created dynamically by the Configuration Monitor component, if 
Configuration is set as one of the services enabled for a given circuit. This is applicable only to 
LAN circuits. The Station subentity is created in response to a received System ID message, 
and records the information contained in that message. 

Note that MOP does not relate the Station and Client subentities in any way. They serve 
unrelated purposes. 

3.3 Support categories 

In the description of attributes below, certain directive arguments and entity attributes are 
flagged to indicate they are required only for some data links. Any arguments or attributes not 
flagged are applicable regardless of data link type. 

All directive arguments shall be accepted by all implementations; when an argument is not 
applicable, it is ignored. Implementations which do not support a particular data link type at 
all must still accept (and ignore) any arguments applicable to the unsupported data link. 

Implementations which don't support a particular data link type may omit any entity attrib- 
utes applicable only to those data links. In that case, attempts to access these attributes are 
rejected (with the standard GetListError or SetListError CMIP error code). 

In this version, the only defined support category is "LAN", which indicates any Local Area 
Network data link, i.e., any of the IEEE 802 family data links, Ethernet, and FDDI. 

3.4 Data type definitions 

The following are the definitions for the management data types used in this chapter. 
FROM Management IMPORT SystemID, P4Address, P4Name; 
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FROM Management IMPORT LAN Address; 
FROM Management IMPORT Octet; 
SAP Address = Octet; 
StatType = 
HelpType = 
OpType = 



FunType = 
SIDFunType = 



DLErrType = 
ServType = 
ProgType = 

SvErrType = 

CircuitType = 
DevType = 
SoftwarelD = String; 



(* A more descriptive type name *) 
(Off = 0, On = 1); 

(None = 0, Transmit = 1 , Receive = 2, Full = 3); 
(Loop Requester = 0, Console Requester = 1 , 
Console Carrier = 2, Load Requester = 3, 
Load Server = 4, Dump Requester = 5, 
Dump Server = 6, Configuration Monitor = 7, 
Test Requester = 8, Query Requester = 9); 
BIT SET OF OpType; 

BIT SET OF (Loop Server = 0, Dump Requester = 1 , 
Primary Loader = 2, Secondary Loader = 3, 
Boot = 4, Console Carrier = 5, Counters = 6); 
(Wrong State = 0, Receive Error = 1 , 
Transmit Error = 2); 

(Load = 0, Dump = 1 , Loop = 2, Boot = 3, 
Test = 4, Query = 5); 

(Secondary Loader = 0, Tertiary Loader = 1 , 
System = 2, Management = 3, CMIP Script = 4, 
Diagnostic = 5); 

(No Resources = 0, Receive Error = 1 , 
Transmit Error = 2, File Open Error = 3, 
File I/O Error = 4, Operation Aborted = 5, 
Unknown Client = 6, Protocol Error = 7, 
Timeout = 8); 

(CSMA-CD = 0, DDCMP = 1 , FDDI = 2, HDLC = 3, 
LAPB = 4, Token Ring = 5, Token Bus = 6, 
Z-LAN = 7); 1 

(* Enumerated, refer to Appendix A.l for code assignments. 
The name to be used for each code is the 3-character 
mnemonic shown there in the "Name" column *); 
(* Software ID is encoded as a text string. However, it must 
conform to the format restrictions documented in Section 
5.5.1. If an invalid value of this data type is supplied to a 
directive, it is rejected with the standard CMIP error return 
Invalid Argument Value. *) 



3.5 MOP Module 

The MOP module is registered in the Distributed Systems Management Registry as shown 
below. 

Class Name: MOP 
Code: 1 6 

Superior Class: Node 



Note that these codes are not the same as the "Data Link Type" codes used in the System ID message, which are 
defined in Appendix A. 2. To simplify the mapping between these two encodings, new values for Circuit Type and 
Data Link Type will be assigned such that the following algorithm applies: 

IF DataLinkType s 10 

THEN CircuitType := LookupTable[DataLinkType] 
ELSE CircuitType := DataLinkType - 5 
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3.5.1 Action Directives 

The MOP module implements the usual directives Create, Delete, Enable, and Disable. In 
addition, it implements five module-specific directives: Loop, Load, Boot, Test, and Query. If an 
implementation does not support some of these functions, the corresponding directive is omitted 
and attempts to invoke it yield the standard Directive Not Supported exception. 

3.5.1.1 MOP module specific action directives 

In order to avoid awkward command language syntax, the five module-specific directives are 
not in fact directives of the module. This is because each directive must refer to a Circuit 
subentity (to identify the circuit to operate on) or a Client subentity (to refer to for directive 
parameters not explicitly specified in the directive) or both. Thus there are actually two sets of 
five directives, one associated with the Client subentity, one with the Circuit subentity. Seman- 
tically these are equivalent, and the only difference in syntax is that one has an optional Circuit 
argument and the other an optional Client argument. If the directive is issued to a Client 
subentity, that subentity is in effect an implied argument of the directive; if the directive is is- 
sued to a Circuit subentity, that subentity is in effect an implied argument. 

In each of these five directives, each argument individually is optional but for any particular 
directive enough parameters must actually be supplied to allow the operation to be performed. 
One possibility is to supply all necessary parameters directly as directive arguments. The other 
possibility is to reference a Client subentity. In that case, the parameters are obtained from the 
Client characteristics, unless overridden by a corresponding argument. 

For each of these five directives, refer to the description below for the list of parameters that 
is necessary to complete the function. If all of these are supplied as arguments, it is not neces- 
sary to include a Client argument. Otherwise, the Client argument must be supplied. If no 
matching Client subentity is found, the request is rejected (Unrecognized Client exception). Oth- 
erwise, any parameters not supplied in the directive itself are obtained from the corresponding 
characteristics of the Client subentity. After completion of this "merge", all necessary parame- 
ters must now be available; if not, the standard CMIP error Required Argument Omitted is re- 
turned. 

Note: 

Since these necessary parameters can be obtained either from the directive ar- 
guments or from the Client database, it is not correct to consider them "required 
arguments" in the sense that they are required to be present on the directive. 
In particular, as far as director processing is concerned, they have to be consid- 
ered as optional arguments. 

The Client subentity attribute Addresses is a Set data type. For the directives, an address 
can be explicitly supplied; if it is not, then the operation proceeds with each of the addresses in 
the Set, until a response is received (except in the case of Boot, which simply loops through the 
entire set since no response is expected). If the set is empty, the request is rejected (standard 
CMIP error Required Argument Omitted). 

3.5.1.2 Create Directive 

The Create directive creates the MOP entity. The Characteristics initially take their default 
values. The Modula-2+ description follows: 

DIRECTIVE Create = : Create; (* Create the MOP entity *) 

REQUEST (* No input arguments *) 

END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 



3.5. 1.3: Delete Directive 
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EXCEPTION Already Exists = 2 : (* MOP Module already exists *) 

END Already Exists; 
END Create; 

PROCEDURE Create ( ) 

RAISES {InsufficientResources}; (* CMIP common error *) 

3.5.13 Delete Directive 



The Delete directive deletes the MOP entity and reclaims any associated resources. The 
Modula-2+ description follows: 

DIRECTIVE Delete = 1 : Delete; (* Delete the MOP entity *) 

REQUEST (* No Input Arguments *) 

END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Has Children = 1 : (* Subentities must be deleted first *) 

END Has Children; 
END Delete; 

PROCEDURE Delete ( ) 
RAISES {}; 

3.5.1.4 Enable Directive 



The Enable directive enables the MOP entity. The Modula-2+ description follows: 



DIRECTIVE Enable = 2 : Enable; 
REQUEST 
END; 

RESPONSE Success = : 
END Success; 
END Enable; 



(* Enable the MOP entity function *) 
(* No input arguments *) 

(* No Output Arguments *) 

(* No Entity-specific Exceptions *) 



PROCEDURE Enable ( ) 
RAISES {}; 



3.5.1.5 Disable Directive 



The Disable directive disables the MOP entity. The Modula-2+ description follows: 

DIRECTIVE Disable = 3 : Disable; (* Disable the MOP entity function *) 

REQUEST (* No input arguments *) 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; (* No Entity-specific Exceptions *) 
END Disable; 

PROCEDURE Disable ( ) 
RAISES {}; 



3.5.2 Identifier Attribute 



Modules do not have an identifier attribute. 
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3.5.3 Characteristic Attributes 

The MOP module has the characteristic attributes shown in Table 1 . 



Table 1: MOP module characteristics attributes 



Keyword 


Code 


Syntax 


Value 


Description 


Version 





VersionNumber 


V4.0.0 


The version of the Maintenance Operations 
specification to which the implementation 
conforms. This attribute is read-only. 


Supported 
Functions 


1 


FunType 


[System 
Specific] 


Specifies which MOP components are avail- 
able in this system. This can be used by the 
Director to avoid issuing directives that use 
omitted functions. This attribute is read- 
only. 



3.5.4 Status Attributes 

The MOP module has the status attributes shown in Table 2. 

Table 2: MOP module status attributes 



Keyword 


Code 


Syntax 


Description 


State 


2 


StatType 


The current State of the MOP module. 



3.5.5 Counter Attributes 

The MOP module does not have any counter attributes. 

3.5.6 Event Reports 

The MOP module does not generate any event reports. 

3.6 Client subentity 

The Client subentity is registered in the Distributed Systems Management Registry as 
shown below. 

Class Name: Client 
Code: 

Superior Class: MOP 

The Client subentity is used by the Load/Dump Server, Loop Requester, Console Requester, 
Test Requester, and Query Requester components of MOP. On systems where none of these are 
implemented, the Client subentity is omitted and any attempts to issue directives to it are re- 
jected (with the standard No Such Entity exception). 



3.6.1: Action Directives 
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3.6.1 Action Directives 



The Client subentity provides action directives for creating and deleting a subentity. These 
directives and the procedures they call are described below. 



3.6.1.1 Create Directive 



The Create directive creates a Client subentity with the specified identifier. The Character- 
istics initially take their default values. The Modula-2+ description follows: 

DIRECTIVE Create = : Create; (* Create a new Client subentity *) 

REQUEST (* No Input Arguments *) 

END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Already Exists = 2 : (* Client subentity already exists *) 

END Already Exists; 
END Create; 



PROCEDURE Create (Identifier: SimpleName) 

RAISES {InsufficientResources}; (* CMIP common error *) 



3.6.1.2 Delete Directive 



The Delete directive deletes a Client subentity and reclaims any associated resources. The 
Modula-2+ description follows: 



DIRECTIVE Delete = 1 : Delete; 
REQUEST 
END; 

RESPONSE Success = : 
END Success; 
END Delete; 



(* Delete an Client subentity *) 
(* No Input Arguments *) 

(* No Output Arguments *) 

(* No Entity-specific Exceptions *) 



PROCEDURE Delete ( Identifier ) 
RAISES {}; 

3.6.13 Loop Directive 



The Loop directive causes a loop test to be performed with another system. 

DIRECTIVE Loop = 4 : Loop; (* Perform a Loop operation with another system *) 

REQUEST 

ARGUMENT Circuit = 1 : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT Assistant System = 4 : SimpleName; 

ARGUMENT Assistant Address = 5 : LANAddress; 

ARGUMENT Assistance Type = 6 : HelpType; 

ARGUMENT Count = 7 : Integer; 

ARGUMENT Length = 8 : Integer; 

ARGUMENT Format = 11: Octet 
END; 

RESPONSE Success = : (* No output arguments *) 

END Success; 

RESPONSE Invalid Response = 1 : 

ARGUMENT Count = 7 : Integer; (* Count of messages successfully looped *) 
END Invalid Response; 
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EXCEPTION Unrecognized Circuit = 1 : (* There is no circuit with the specified identification *) 
END Unrecognized Circuit; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Assistant = 5 : (* No assistant with the specified identification *) 
END Unrecognized Assistant; 

EXCEPTION Invalid Assistant = 6 : (* The Assistant Address is either a multicast address, or 

Assistant System was specified but the corresponding Client 
subentity has an empty Addresses list *) 



END Invalid Assistant; 
EXCEPTION Timeout = 7 : 
END Timeout; 

END Loop; 



(* No response was received in the timeout period *) 



PROCEDURE Loop (Client, Circuit, Address, AssistantSystem, 

AssistantAddress, AssistanceType, Count, Length, Format) 
RAISES {InvalidResponse, 
InsufficientResources , 
UnrecognizedCircuit, 
DataLinkError, 
UnrecognizedClient, 
Required ArgumentOmitted , 
UnrecognizedAssistant, 
InvalidAssistant, 
Invalid ArgumentValue , 
Timeout}; 



(* CMIP common error *) 



(* Does not apply here *) 
(* CMIP common error *) 



(* CMIP common error *) 



For LAN circuits, if Assistance Type is None, the operation is a Loop-direct; If 
AssistanceType is some other value, the operation is Loop-assisted. For Loop-assisted, the de- 
fault assistant address is the Loop Assistant multicast address. A different address may be 
specified by including the Assistant Address parameter, which specifies the address directly, or 
by specifying Assistant System, which specifies a name of a Client subentity. The Addresses 
characteristic of the named Client subentity is then used as the assistant address. On non- 
LAN circuits, the Assistant Address, Assistant System, and Assistance Type arguments are ig- 
nored. 



The required parameters are: 
• Circuit 

Address (for LAN circuits) 



The defaults values for the optional parameters are: 

Assistance Type — None 

• Assistant Address — Obtained dynamically: an assistant is found by sending a direct 
(non-assisted) Loop request to the Loop Assistance multicast address. If a response is 
received, the responding station is then used as the assistant for the rest of the opera- 
tion. 



• Count — 1 

• Length — 40 
Format — %x55 



3. 6. 1 .4: Load Directive 
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3.6.1.4 Load Directive 



The Load directive causes a down line load to be performed to another system. A Boot is 
done first to force the specified system to load. 

DIRECTIVE Load = 5 : Load; (* Force load an adjacent system *) 

REQUEST 

ARGUMENT Circuit = 1 : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT System Image = 3 : FileSpec; 

ARGUMENT Script File = 4 : FileSpec; 

ARGUMENT Secondary Loader = 5 : FileSpec; 

ARGUMENT Tertiary Loader = 6 : FileSpec; 

ARGUMENT Verification = 7 : OctetString; 

ARGUMENT Management Image = 8 : FileSpec; 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Unrecognized Circuit = 1 : (* There is no circuit with the specified identification *) 
END Unrecognized Circuit; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Protocol Error = 5; (* A protocol error occurred during the load *) 

END Protocol Error; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Load; 

PROCEDURE Load (Client, Circuit, Address, Systemlmage, ScriptFile, Managementlmage, 
SecondaryLoader, TertiaryLoader, Verification) 
RAISES {InsufficientResources, (* CMIP common error *) 

UnrecognizedCircuit, 
DataLinkError, 

UnrecognizedClient, (* Does not apply here *) 

RequiredArgumentOmitted, (* CMIP common error *) 

ProtocolError, 

In valid ArgumentValue, (* CMIP common error *) 

Timeout}; 



Required parameters are: 
• Circuit 



• Address (for LAN circuits) 
System Image 

• Script File (if requested by target system) 

• Secondary Loader (if requested by target system) 

• Tertiary Loader (if requested by target system) 
Management Image (if requested by target system) 

The default values for the optional parameters are: 

• Verification — %x0000000000000000 
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3.6.1.5 Boot directive 



The Boot directive causes a Boot message to be sent to another system. 

DIRECTIVE Boot = 6 : Boot; (* Send a Boot trigger to an adjacent system *) 

REQUEST 

ARGUMENT Circuit = 1 : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT Verification = 7 : OctetString; 

ARGUMENT Device = 8 : String; 

ARGUMENT Software ID = 9 : SoftwarelD; 

ARGUMENT Script ID = 10 : SoftwarelD; 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Unrecognized Circuit = 1 : (* There is no circuit with the specified identification *) 
END Unrecognized Circuit; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 
END Boot; 

PROCEDURE Boot (Client, Circuit, Address, Verification, Device, SoftwarelD, ScriptID) 
RAISES {InsufficientResources, (* CMIP common error *) 

UnrecognizedCircuit, 
DataLinkError, 

UnrecognizedClient, (* Does not apply here *) 

Invalid ArgumentValue, (* CMIP common error *) 

Required ArgumentOmitted}; (* CMIP common error *) 



Required parameters are: 
Circuit 



Address (for LAN circuits) 
The default values for the optional parameters are: 
• Verification — %x0000000000000000 



Note: 

The default value for the Verification parameter is a default only. It is not a 
"wild card" value. For any value of the Verification parameter including the de- 
fault value, the Console Server (target of the directive) will check the value and 
accept the operation only if the value matches the one expected. 



3.6.1.6 Test Directive 



The Test directive causes the IEEE 802.2 Test to be performed with another system. If ap- 
plied to the wrong type of data link (i.e., non-LAN), the standard error Directive Not Supported is 
returned. 

DIRECTIVE Test = 7 : Test; (* Perform a Test operation with another system *) 

REQUEST 

ARGUMENT Circuit = 1 : SimpleName; 
ARGUMENT Address = 2 : LANAddress; 
ARGUMENT Count = 7 : Integer; 
ARGUMENT Length = 8 : Integer; 



3.6.1.7: Query Directive 
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ARGUMENT SAP = 10 : SAP Address; 
ARGUMENT Format = 11: Octet; 
END; 

RESPONSE Success = : (* No output arguments *) 

END Success; 

RESPONSE Invalid Response = 1 : 

ARGUMENT Count = 7 : Integer; (* Count of messages successfully looped *) 
END Invalid Response; 

EXCEPTION Unrecognized Circuit = 1 : (* There is no circuit with the specified identification *) 
END Unrecognized Circuit; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Test; 



PROCEDURE Test (Client, Circuit, t 
RAISES {InvalidResponse, 
Insuff icientResources , 
UnrecognizedCircuit, 
DataLinkError, 
UnrecognizedClient, 
RequiredArgumentOmitted , 
DirectiveNotSupported 
Invalid ArgumentValue , 
Timeout); 



, Count, Length, SAP, Format) 
(* CMIP common error *) 



(* Does not apply here *) 
(* CMIP common error *) 
(* CMIP common error *) 
(* CMIP common error *) 



The required parameters are: 
Circuit 



• Address 



The defaults values for the optional parameters are: 
• Count— 1 



• Length — 40 

• SAP — 

• Format — %x55 



3.6.1.7 Query Directive 



The Query directive causes an IEEE 802.2 XID exchange to be performed with another sys- 
tem. If applied to the wrong type of data link (i.e., non-LAN), the standard error Directive Not 
Supported is returned. 

DIRECTIVE Query = 8 : Query; (* Perform an XID exchange with another system *) 

REQUEST 

ARGUMENT Circuit = 1 : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT SAP = 10 : SAP Address; 
END; 

RESPONSE Success = : 

ARGUMENT LLC Types = 10 : Set of Integer; (* LLC types supported by system *) 
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ARGUMENT Window = 11: Integer (* Window size for Type 2 LLC *) 
END Success; 

RESPONSE Invalid Response = 1 : (* Protocol error in response *) 
END Invalid Response; 

EXCEPTION Unrecognized Circuit = 1 : (* There is no circuit with the specified identification *) 
END Unrecognized Circuit; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Query; 

PROCEDURE Query (Client, Circuit, Address, 
RAISES {InvalidResponse, 
InsufficientResources , 
UnrecognizedCircuit, 
DataLinkError, 
UnrecognizedClient, 
Required ArgumentOmitted , 
DirectiveNotSupported , 
Invalid ArgumentValue , 
Timeout); 

The required parameters are: 

Circuit 

Address 

The defaults values for the optional parameters are: 
• SAP — 

3.6.2 Identifier Attribute 

The identifier attributes for each Client subentity are shown in Table 3. 



Table 3: Client entity identifier attribute 



Keyword 


Code 


Syntax 


Description 


Name 





SimpleName 


A string which is the Identifier for the Client (tar- 
get system) and which is unique among the set of 
Clients defined for the MOP module. 



SAP, LLCTypes, Window) 
(* CMIP common error *) 



(* Does not apply here *) 
(* CMIP common error *) 
(* CMIP common error *) 
(* CMIP common error *) 



3.6.3: Characteristic Attributes 
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3.6.3 Characteristic Attributes 

The characteristics attributes for each Client subentity are shown in Tables 4 and 5. 



Table 4: Client entity characteristics attributes (part 1) 



Keyword 


Code 


Note 


Syntax 


Default 


Description 


Circuit 


1 




SimpleName 




The name of the Circuit subentity 
(of the MOP module) that corre- 
sponds to the data link circuit to 
be used for communicating with 
this client. 


Addresses 


2 


LAN 


Set of 

LANAddress 


{} 


The Set of LAN addresses for this 
client on the circuit specified by 
the Circuit characteristic. These 
addresses may not be multicast 
addresses (see note below). 


Secondary 
Loader 


3 




Sequence of 
FileSpec 


() 


The files to be loaded when the 
client requests "Secondary 
Loader" during a down line load 
operation. The file identification 
is interpreted depending on the 
file system of the local system. 


Tertiary 
Loader 


4 




Sequence of 
FileSpec 


() 


The files to be loaded when the 
client requests "Tertiary Loader" 
during a down line load operation. 
The file identification is inter- 
preted depending on the file sys- 
tem of the local system. 


System Image 


5 




Sequence of 
FileSpec 


() 


The files to be loaded when the 
client requests "Operating Sys- 
tem" (i.e., Program Type = Sys- 
tem Image, Software ID = 
Standard Operating System) dur- 
ing a down line load operation. 
The file identification is inter- 
preted depending on the file sys- 
tem of the local system. 


Diagnostic Im- 
age 


6 




Sequence of 
FileSpec 


() 


The files to be loaded when the 
client requests "Maintenance Sys- 
tem" (i.e., Program Type = Sys- 
tem Image, Software ID = 
Maintenance System) during a 
down line load operation. The 
file identification is interpreted 
depending on the file system of 
the local system. 
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Table 5: Client entity characteristics attributes (part 2) 



Keyword 


Code 


Note 


Syntax 


Default 
Value 


Description 


Management 
Image 


1 




Sequence of 
FileSpec 


( ) 


The files to be loaded when the 
client requests "Management Im- 
age" during a down line load op- 
eration. The file identification is 
interpreted depending on the file 
system of the local system. 


Script File 


8 




Sequence of 
FileSpec 


() 


The files to be loaded when the 
client requests CMIP Initializa- 
tion Script" during a down line 
load operation. The file identifi- 
cation is interpreted depending on 
the file system of the local sys- 
tem. 


Phase IV Host 
Name 


9 




P4Name 




The host name that the client re- 
ceives when it is down line 
loaded. 


Phase IV Host 
Address 


10 




P4Address 


0.0 


The host address that the client re- 
ceives when it is down line 
loaded. 


Phase IV Cli- 
ent Name 


11 




P4Name 




The client name that the client re- 
ceives when it is down line 
loaded. 


Phase IV Cli- 
ent Address 


12 




P4Address 


0.0 


The client address that the client 
receives when it is down line 
loaded. 


Dump File 


13 




Sequence of 
FileSpec 


() 


The identification of the files to 
write to when the client is up line 

Hnmnprl "rhp "Flip iHpntifipatinn it; 

interpreted depending on the file 
system of the local system. 


Dump Address 


14 




Integer 





The memory address at which to 
begin an up line dump 


Verification 


16 




OctetString 


%x0000000 
000000000 


The verification string to be sent 
in a Boot message to this client. 
See note below. 


Device Types 


17 




SET OF 
DevType 


{} 


The Set of Device Types for this 
client on the circuit specified by 
the Circuit characteristic. 



Note: 

The address values in the Addresses parameters must be individual addresses, 
not group (multicast) addresses. The length of the Verification attribute must be 
s8. Attempts to set invalid values in these attribute are rejected with the CMIP 
standard error Invalid Attribute Value. 



3.6.4: Status Attributes 
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3.6.4 Status Attributes 

The Client subentity does not have any status attributes. 

3.6.5 Counter Attributes 

The Client subentity does not have any counter attributes. 

3.6.6 Event Reports 

The Client subentity does not generate any event reports. 

3.7 Circuit subentity 

The Circuit subentity is registered in the Distributed Systems Management Registry as 
shown below. 

Class Name: Circuit 
Code: 1 

Superior Class: MOP 

3.7.1 Action Directives 

The Circuit subentity provides action directives for creating and deleting a subentity, and for 
enabling and disabling the various MOP functions. These directives and the procedures they 
call are described below. 

3.7.1.1 Create Directive 

The Create directive creates a Circuit subentity with the specified identifier. The Character- 
istics initially take their default values. The Modula-2+ description follows: 

DIRECTIVE Create = : Create; (* Create a new Circuit subentity *) 

REQUEST 

ARGUMENT Type = : CircuitType; 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Unsupported Circuit Type = 1 : (* The specified Type argument value is not supported in 

this implementation *) 

END Unsupported Circuit Type; 

EXCEPTION Already Exists = 2 : (* Circuit subentity already exists *) 

END Already Exists; 
END Create; 

PROCEDURE Create (Identifier: SimpleName, Type: CircuitType) 

RAISES {InsufficientResources, (* CMIP common error *) 

UnsupportedCircuitType} ; 

3.7.1.2 Delete Directive 

The Delete directive deletes a circuit subentity and reclaims any associated resources. The 
Modula-2+ description follows: 
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DIRECTIVE Delete = 1 : Delete; 
REQUEST 
END; 

RESPONSE Success = : 
END Success; 

EXCEPTION Has Children = 1 
END Has Children; 
END Delete; 

PROCEDURE Delete ( Identifier ) 
RAISES {}; 

3.7.1.3 Enable Directive 

The Enable directive enables a particular MOP function for the specified circuit. The func- 
tion to be enabled is supplied as an argument. The Modula-2+ description follows: 

DIRECTIVE Enable = 2 : Enable; (* Enable a Circuit subentity function *) 

REQUEST 

ARGUMENT Functions = : FunType; 
END; 

RESPONSE Success = : 
END Success; 

EXCEPTION Unsupported Function 



END Unsupported Function; 
EXCEPTION Nonexistent Data Link 
END Nonexistent Data Link; 
EXCEPTION Open Port Failed = 2 : 
END Open Port Failed; 
END Enable; 

PROCEDURE Enable (Function: FunType) 

RAISES {Unsupported, NonexistentDataLink, OpenPortFailed}; 

3.7.1.4 Disable Directive 

The Disable directive disables a particular MOP function for the specified circuit. The func- 
tion to be disabled is supplied as an argument. The argument is optional; the default is to dis- 
able all functions (i.e., all that are currently enabled). The Modula-2+ description follows: 

DIRECTIVE Disable = 3 : Disable; (* Disable a Circuit subentity function *) 

REQUEST 

ARGUMENT Functions = : FunType; 

DEFAULT = { Loop Requester, Console Requester, Console Carrier, Load Requester, 

Load Server, Dump Requester, Dump Server, 
Configuration Monitor, Test Requester, Query Requester } 

END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; (* No Entity-specific Exceptions *) 

END Disable; 



(* Delete an Circuit subentity *) 
(* No Input Arguments *) 

(* No Output Arguments *) 

(* No Entity-specific Exceptions *) 

(* Subentities must be deleted first *) 



(* No Output Arguments *) 

= : (* The specified function is not supported, either not 

at all by the implementation, or not for this particular data 
link type. *) 

= 1 : (* The specified Data Link entity does not exist *) 

(* The Open Port operation failed *) 



PROCEDURE Disable (Function: FunType) 
RAISES {}; 



3. 7. 1 .5: Loop Directive 
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3.7.1.5 Loop Directive 



The Loop directive causes a loop test to be performed with another system. 

DIRECTIVE Loop = 4 : Loop; (* Perform a Loop operation with another system *) 

REQUEST 

ARGUMENT Client = : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT Assistant System = 4 : SimpleName; 

ARGUMENT Assistant Address = 5 : LANAddress; 

ARGUMENT Assistance Type = 6 : HelpType; 

ARGUMENT Count = 7 : Integer; 

ARGUMENT Length = 8 : Integer; 

ARGUMENT Format = 11: Octet 
END; 

RESPONSE Success = : 
END Success; 

RESPONSE Invalid Response = 1 : 

ARGUMENT Count = 7 : Integer; 
END Invalid Response; 
EXCEPTION Data Link Error = 2 : 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Client = 3 : (* There is no client with the specified identification *) 
END Unrecognized Client; 

EXCEPTION Unrecognized Assistant = 5 : (* No assistant with the specified identification *) 
END Unrecognized Assistant; 

EXCEPTION Invalid Assistant = 6 : (* The Assistant Address is either a multicast address, or 

Assistant System was specified but the corresponding Client 
subentity has an empty Addresses list *) 

END Invalid Assistant; 

EXCEPTION Timeout -7 : (* No response was received in the timeout period *) 

END Timeout; 
END Loop; 



(* No output arguments *) 

(* Count of messages successfully looped *) 

(* An error was reported by the Data Link layer *) 



PROCEDURE Loop (Client, Circuit, Address, AssistantSystem, 

AssistantAddress, AssistanceType, Count, Length, Format) 
RAISES {InvalidResponse, 
Insuff icientResources , 
UnrecognizedCircuit , 
DataLinkError, 
UnrecognizedClient, 
RequiredArgumentOmitted , 
UnrecognizedAssistant, 
InvalidAssistant, 
Invalid Argument Value , 
Timeout}; 



(* CMIP common error *) 
(* Does not apply here *) 



(* CMIP common error *) 



(* CMIP common error *) 



For LAN circuits, if Assistance Type is None, the operation is a Loop-direct; If Assistance 
Type is some other value, the operation is Loop-assisted. For Loop-assisted, the default assis- 
tant address is the Loop Assistant multicast address. A different address may be specified by 
including the Assistant Address parameter, which specifies the address directly, or by specifying 
Assistant System, which specifies a name of a Client subentity. The Addresses characteristic of 
the named Client subentity is then used as the assistant address. On non-LAN circuits, the 
Assistant Address, Assistant System, and Assistance Type arguments are ignored. 



The required parameters are: 
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Address (for LAN circuits) 
The defaults values for the optional parameters are: 
Assistance Type — None 

• Assistant Address — Obtained dynamically: an assistant is found by sending a direct 
(non-assisted) Loop request to the Loop Assistance multicast address. If a response is 
received, the responding station is then used as the assistant for the rest of the opera- 
tion. 

• Count — 1 
Length — 40 

• Format — %x55 
3.7.1.6 Load Directive 



The Load directive causes a down line load to be performed to another system. A Boot is 
done first to force the specified system to load. 

DIRECTIVE Load = 5 : Load; (* Force load an adjacent system *) 

REQUEST 

ARGUMENT Client = : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT System Image = 3 : FileSpec; 

ARGUMENT Script File = 4 : FileSpec; 

ARGUMENT Secondary Loader = 5 : FileSpec; 

ARGUMENT Tertiary Loader = 6 : FileSpec; 

ARGUMENT Verification = 7 : OctetString; 

ARGUMENT Management Image = 8 : FileSpec; 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Client = 3 : (* There is no client with the specified identification *) 
END Unrecognized Client; 

EXCEPTION Protocol Error = 5; (* A protocol error occurred during the load *) 

END Protocol Error; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Load; 

PROCEDURE Load (Client, Circuit, Address, LoadFile, ScriptFile, Managementlmage, 
SecondaryLoader, TertiaryLoader, Verification) 
RAISES {InsufficientResources, (* CMIP common error *) 

UnrecognizedCircuit, (* Does not apply here *) 

DataLinkError, 
UnrecognizedClient, 

Required ArgumentOmitted, (* CMIP common error *) 

ProtocolError, 

Invalid Argument Value, (* CMIP common error *) 

Timeout}; 



Required parameters are: 



3.7.1. 7: Boot directive 



Address (for LAN circuits) 
System Image 

Script File (if requested by target system) 
Secondary Loader (if requested by target system) 
Tertiary Loader (if requested by target system) 
Management Image (if requested by target system) 
The default values for the optional parameters are: 

• Verification — %x0000000000000000 
3.7.1.7 Boot directive 

The Boot directive causes a Boot message to be sent to another system. 

DIRECTIVE Boot = 6 : Boot; (* Send a Boot trigger to an adjacent system *) 

REQUEST 

ARGUMENT Client = : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT Verification = 7 : OctetString; 

ARGUMENT Device = 8 : String; 

ARGUMENT Software ID = 9 : SoftwarelD; 

ARGUMENT Script ID = 10 : SoftwarelD; 
END; 

RESPONSE Success = : (* No Output Arguments *) 

END Success; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Client = 3 : (* There is no client with the specified identification *) 
END Unrecognized Client; 
END Boot; 

PROCEDURE Boot (Client, Circuit, Address, Verification, Device, SoftwarelD, ScriptID) 
RAISES {InsufficientResources, (* CMIP common error *) 

UnrecognizedCircuit, (* Does not apply here *) 

DataLinkError, 
UnrecognizedClient, 

In valid ArgumentValue, (* CMIP common error *) 

RequiredArgumentOmitted}; (* CMIP common error *) 

Required parameters are: 

• Address (for LAN circuits) 

The default values for the optional parameters are: 

• Verification — %x0000000000000000 

Note: 

The default value for the Verification parameter is a default only. It is not a 
"wild card" value. For any value of the Verification parameter including the de- 
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fault value, the Console Server (target of the directive) will check the value and 
accept the operation only if the value matches the one expected. 



3.7.1.8 Test Directive 



The Test directive causes the IEEE 802.2 Test to be performed with another system. If ap- 
plied to the wrong type of data link (i.e., non-LAN), the standard error Directive Not Supported is 
returned. 

DIRECTIVE Test = 7 : Test; (* Perform a Test operation with another system *) 

REQUEST 

ARGUMENT Client = : SimpleName; 
ARGUMENT Address = 2 : LANAddress; 
ARGUMENT Count = 7 : Integer; 
ARGUMENT Length = 8 : Integer; 
ARGUMENT SAP = 10 : SAPAddress; 
ARGUMENT Format = 11: Octet; 
END; 

RESPONSE Success = : (* No output arguments *) 

END Success; 

RESPONSE Invalid Response = 1 : 

ARGUMENT Count = 7 : Integer; (* Count of messages successfully looped *) 
END Invalid Response; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Client = 3 : (* There is no client with the specified identification *) 
END Unrecognized Client; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Test; 



PROCEDURE Test (Client, Circuit, i 
RAISES {InvalidResponse, 
InsufficientResources , 
UnrecognizedCircuit, 
DataLinkError, 
UnrecognizedClient, 
Required ArgumentOmitted , 
DirectiveNotSupported , 
Invalid Argument Value , 
Timeout); 



, Count, Length, SAP, Format) 

(* CMIP common error *) 
(* Does not apply here *) 



(* CMIP common error *) 
(* CMIP common error *) 
(* CMIP common error *) 



The required parameters are: 
Address 



The defaults values for the optional parameters are: 
• Count — 1 



• Length — 40 

• SAP — 
Format — %x55 



3.7.1.9: Query Directive 
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3.7.1.9 Query Directive 

The Query directive causes an IEEE 802.2 XID exchange to be performed with another sys- 
tem. If applied to the wrong type of data link (i.e., non-LAN), the standard error Directive Not 
Supported is returned. 

DIRECTIVE Query = 8 : Query; (* Perform an XID exchange with another system *) 

REQUEST 

ARGUMENT Client = : SimpleName; 

ARGUMENT Address = 2 : LANAddress; 

ARGUMENT SAP = 10 : SAPAddress; 
END; 

RESPONSE Success = : 

ARGUMENT LLC Types = 10 : Set of Integer; (* LLC types supported by system *) 

ARGUMENT Window = 11: Integer (* Window size for Type 2 LLC *) 
END Success; 

RESPONSE Invalid Response = 1 : (* Protocol error in response *) 
END Invalid Response; 

EXCEPTION Data Link Error = 2 : (* An error was reported by the Data Link layer *) 

ARGUMENT Reason = : DLErrType; 
END Data Link Error; 

EXCEPTION Unrecognized Client = 3 : (* There is no client with the specified identification *) 
END Unrecognized Client; 

EXCEPTION Timeout = 7 : (* No response was received in the timeout period *) 

END Timeout; 
END Query; 

PROCEDURE Query (Client, Circuit, Address, 
RAISES {InvalidResponse, 
InsufficientResources , 
UnrecognizedCircuit, 
DataLinkError, 
UnrecognizedClient, 
RequiredArgumentOmitted , 
DirectiveNotSupported, 
Invalid Argument Value , 
Timeout); 

The required parameters are: 

• Address 

The defaults values for the optional parameters are: 

• SAP — 

3.7.2 Identifier Attribute 

The identifier attributes for each Circuit subentity are shown in Table 6. 



SAP, LLCTypes, Window) 

(* CMIP common error *) 
(* Does not apply here *) 

(* CMIP common error *) 
(* CMIP common error *) 
(* CMIP common error *) 
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Table 6: Circuit entity identifier attribute 



Keyword 


Code 


Syntax 


Description 


Name 





SimpleName 


A string which is the Identifier for the Circuit and 
which is unique among the set of Circuits defined 
for the MOP module. 



3.7.3 Characteristic Attributes 



The characteristics attributes for each Circuit subentity are shown in Table 7. 



Table 7: Circuit entity characteristics attributes 



Keyword 


Code 


Syntax 


Default 
Value 


Description 


Type 


1 


CircuitType 




The type of the Circuit, set when the Circuit 
subentity is created. This is a read-only char- 
acteristic. 


Link Name 


2 


Local Entity 
Name 




The name of the Station subentity in the Data 
Link layer module indicated by the Type 
characteristic. This is passed to the Data 
Link layer module when MOP opens a port 
for the circuit. 


Retransmit 
Timer 


3 


Integer [1.. 30] 


4 


The time-out value to use (in seconds) for 
retransmitting MOP protocol messages when 
no response is received. 


Known Clients 
Only 


13 


Boolean 


FALSE 


TRUE if Load service is to be limited only to 
clients listed in the Client database, even if a 
Software ID string is supplied by the client. 



3.7.4 Status Attributes 

The status attributes for each Circuit subentity are shown in Table 8. 

Table 8: Circuit entity status attribute 



Keyword 


Code 


Syntax 


Description 


UID 


4 


UID 


The UID of this entity, allocated when it was cre- 
ated. 


Functions 


6 


FunType 


The set of functions currently enabled for this cir- 
cuit. Only the functions that can be enabled and 
disabled are shown; functions required to be ac- 
tive at all times are not. 



3.7.5: Counter Attributes 31 



3.7.5 Counter Attributes 

The counter attributes for each Circuit subentity are shown in Table 9. 



Table 9: Circuit entity counter attributes 



Keyword 


Code 


Syntax 


Description 


Creation Time 


5 


Binary Absolute 
Time 


The time at which the entity was created. This in- 
dicates the time at which the associated Counter 
attributes were zero 


Load Requests 
Completed 


7 


Counter 


The number of Load service requests completed 
successfully. 


Unrecognized Load 
Clients 


8 


Counter 


The number of Load service requests that could 
not be processed because a Client database entry 
was required but no matching entry was found. 


Failed Load Re- 
quests 


9 


Counter 


The number of Load service requests that could 
not be completed. 


Dump Requests 
Completed 


10 


Counter 


The number of Dump service requests completed 
successfully. 


Unrecognized Dump 
Clients 


11 


Counter 


The number of Dump service requests that could 
not be processed because a Client database entry 
was required but no matching entry was found. 


Failed Dump Re- 
quests 


12 


Counter 


The number of Dump service requests that could 
not be completed. 



3.7.6 Event Reports 

The Circuit subentity generates six events. The event arguments are described in Table 10. 



Table 10: Circuit entity event arguments 



Keyword 


Code 


Syntax 


Description 


Reason 


1 


SvErrType 


The reason for the operation failure. 


Address 


2 


LANAddress 


The Data Link address of the remote system. 
Supplied only for LAN Data Links. 


Client 


4 


SimpleName 


The name of the Client subentity corresponding 

to the remote system. 

If unavailable, this argument is omitted. 


Program Type 


5 


ProgType 


The Program Type requested by the remote sys- 
tem. Applicable only for Load requests; omitted 
otherwise. 


File 


6 


FileSpec 


The file name of the file being processed. For 
Load requests, this is the file being loaded. For 
Dump requests, this is the Dump File name. 
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The events definitions are as follows: 

EVENT Load Request Completed =0; (* A Load service requested by a remote Dump/Load 

requester has completed successfully *) 

COUNTED AS Load Requests Completed; 

ARGUMENTS Address, Client, Program Type, File; 
END Load Request Completed; 

EVENT Unrecognized Load Client =1; (* A Load service requested by a remote Dump/Load 

requester was not accepted because a Client database entry 
was needed but no matching entry was found *) 
COUNTED AS Unrecognized Load Clients; 
ARGUMENTS Address, Program Type; 
END Unrecognized Load Client; 

EVENT Load Request Failed = 2; (* A Load requested by a remote Dump/Load requester has 

failed. Note that the case of unrecognized client (where the 
request was never started due to insufficient information) is 
reported using the event above. *) 

COUNTED AS Failed Load Requests; 
ARGUMENTS Reason, Address, Client, Program Type, File; 
END Load Request Failed; 

EVENT Dump Request Completed = 3; (* A Dump service requested by a remote Dump/Load 

requester has completed successfully *) 

COUNTED AS Dump Requests Completed; 

ARGUMENTS Address, Client, File; 
END Dump Request Completed; 

EVENT Unrecognized Dump Client = 4; (* A Dump service requested by a remote Dump/Load 

requester was not accepted because a Client database entry 
was needed but no matching entry was found *) 
COUNTED AS Unrecognized Dump Clients; 
ARGUMENTS Address; 
END Unrecognized Dump Client; 

EVENT Dump Request Failed = 5; (* A Dump requested by a remote Dump/Load requester has 

failed. Note that the case of unrecognized client (where the 
request was never started due to insufficient information) is 
reported using the event above. *) 

COUNTED AS Failed Dump Requests; 
ARGUMENTS Reason, Address, Client, File; 
END Dump Request Failed; 

3.8 Operation subentity 

The Operation subentity is registered in the Distributed Systems Management Registry as 
shown below. 

Class Name: Operation 
Code: 

Superior Class: Circuit 

3.8.1 Action Directives 

The Operation subentity does not have any action directives. 

3.8.2 Identifier Attribute 

The identifier attributes for each Operation subentity are shown in Table 11. 
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Table 1 1 : Operation entity identifier attribute 



Keyword 


Code 


Syntax 


Description 


Name 





SimpleName 


A string which identifies the operation and is 
unique among the set of Operation subentities for 
this circuit. The suggested way to generate this 
identifier is to use the external (user visible) rep- 
resentation of the Data Link address for the client 
system, with a suffix to distinguish it from other 
concurrent operations involving the same system. 



3.8.3 Characteristic Attributes 

The Operation subentity does not have any characteristic attributes. 

3.8.4 Status Attributes 

The status attributes for each Operation subentity are shown in Table 12. 

Table 12: Operation entity status attributes 



Keyword 


Code 


Syntax 


Description 


Operation 


1 


ServType 


The operation being performed. 


Address 


2 


LANAddress 


The Data Link address for the client system. 


Client 


3 


SimpleName 


The Client name of the client system, if available. 
If a Client Database reference was necessary to 
process the operation, this attribute will be non- 
null. If not (i.e., all required parameters were 
supplied) the implementation may optionally look 
for a matching Client Database entry anyway and 
provide the Client name, if a match was found. 
Otherwise, this attribute will be a null Simple 
Name. 



3.8.5 Counter Attributes 

The Operation subentity does not have any counter attributes. 

3.8.6 Event Reports 

The Operation subentity does not generate any event reports. 

3.9 Station subentity 

The Station subentity is registered in the Distributed Systems Management Registry as 
shown below. 

Class Name: Station 
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Code: 1 

Superior Class: Circuit 

The Station subentity is created by the Configuration Monitor component, to report stations 
observed on the network. 

3.9.1 Action Directives 

The Station subentity does not have any action directives. 

3.9.2 Identifier Attribute 

The identifier attributes for each station subentity are shown in Table 13. 



Table 13: Station entity identifier attribute 



Keyword 


Code 


Syntax 


Description 


Name 





SimpleName 


A string which identifies the station and is unique 
among the set of Station subentities for this cir- 
cuit. The suggested way to generate this identi- 
fier is to use the external (user visible) 
representation of the Data Link address for this 
station, i.e., the source address of the System ID 
message from which this Station subentity was 
created. 



3.9.3 Characteristic Attributes 

The Station subentity does not have any characteristic attributes. 

3.9.4 Status Attributes 

The status attributes for each Station subentity are shown in Table 14. 



3.9.5: Counter Attributes 
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Table 14: Station entity status attributes 



Keyword 


Code 


Syntax 


Description 


Last Report 


1 


Binary Absolute 
Time 


The time at which the most recent System ID 
message was received from this system. 


MOP Version 


2 


Version 


The MOP Protocol version received from the sys- 
tem. 


Functions 


3 


SIDFunType 


The set of functions implemented by this system. 
Note that the "Console Carrier Reserved" bit from 
the System ID message is not reflected here, but 
rather in the Console User status . 


Console User 


4 


LANAddress 


The Data Link address of the system that cur- 
rently has the console reserved, or the Null ad- 
dress if the console is not reserved. 


Reservation Timer 


5 


Integer 


The Console reservation timer, in seconds, or zero 
if not applicable. 


Command Size 


6 


Integer 


The maximum Console command size, in bytes, 
or zero if not applicable. 


Response Size 


7 


Integer 


The maximum Console response size, in bytes, or 
zero if not applicable. 


Hardware Address 


8 


LANAddress 


The hardware address (default data link address) 
for the circuit on which the System ID message 
was sent by the system. 


Device Type 


9 


DevType 


The communication device type for the circuit on 
which the System ID was sent by the system. Re- 
fer to Appendix A.l for the current list of codes 
assigned for this data type. 


Data Link 


10 


CircuitType 


The data link protocol for the circuit on which the 
System ID was sent by the system. The code as- 
signments for type data type are shown in Section 
3.4. 


DSDU Size 


11 


Integer 


The DSDU size for the circuit on which the Sys- 
tem ID was sent by the system. That is, the maxi- 
mum length of the message passed between MOP 
and the Data Link layer module, excluding any 
Data Link envelope. 


Node Name 


13 


FullName 


The node name of the node. Null if not reported 
or if reported as null by the node. 


Node ID 


14 


LANAddress 


The node ID of the node, or the null address (00- 
00-00-00-00-00) if not reported by the remote 
node. 



3.9.5 Counter Attributes 

The Station subentity does not have any counter attributes. 
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3.9.6 Event Reports 

The Station subentity does not generate any event reports. 
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This chapter presents the MOP algorithms in detail. The description is mostly pseudo-code 
in Modula-2-Plus, with some portions described in English where this is clearer. The structure 
of the algorithms is intended to facilitate understanding; there is no requirement that actual 
implementations structure their algorithms in a similar way, only that the externally visible 
behavior (i.e., protocol messages, network management output) is the same. 

The algorithms shown include support for compatibility with MOP V3. Refer to Appendix G 
for more information. 

The definitions and algorithms in this chapter are organized as follows: 

• Common definitions: constants, datatypes, etc. 

• Top level management directive processing 

• Top level algorithms for the MOP client and server functions 

• Common low level protocol primitives 

• Data link dependent protocol primitives 

• Miscellaneous low level procedures 

4.1 Notes on the operational model 

As can be seen from the MOP component model (as shown in Chapter 2), MOP consists of a 
number of fairly independent protocol entities. In addition, many of these components may be 
engaged in more than one operation at a time. 

In a practical implementation, MOP will need to have a number of threads for its various 
functions (and, in cases such as load/dump servers, multiple threads for multiple instances of 
the same function). 

The algorithmic description in this chapter glosses over some detail in an attempt to reduce 
the amount of unnecessary clutter. These include: 

• Thread creation, scheduling, and deletion is not shown. However, the Operation record 
type declaration does show (approximately) the per-thread state needed to describe each 
operation thread. 
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• The description of each thread assumes that there is a receive dispatcher that sorts out 
the received messages and passes to each thread only those messages that concern it 
(see Section 4.12). 

• Parsing and validation of incoming messages is generally not shown. The general rule 
is that any unexpected or invalid message should be treated as if it had not been re- 
ceived at all. Note that this means that timers and retry counters should not be reset 
when such a message is received. In a few cases this rule is called out explicitly with 
the pesudo-statement « quietly ignore the message ». 

Note: 

Note that this means that unexpected, erroneous, malformed, or otherwise ille- 
gal messages are normally not cause for aborting the operation with a "Protocol 
error" result. The few exceptions to this rule are called out explicitly in the al- 
gorithms below. 

• In a number of cases, the algorithms have to attempt request/response exchanges with 
several possible addresses and/or version numbers. The algorithms below try each com- 
bination sequentially. An implementation may instead do some or all of the possible 
combination in parallel for efficiency. For some protocol exchanges (e.g., Loop) care 
must be taken not to confuse the replies; the receipt number in the message can be used 
to do this. 

4.2 Common definitions 

4.2.1 Architectural constants 

Table 15 below lists the MOP architectural constants with the name by which they are re- 
ferred to in this chapter. 
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Table 15: MOP Architectural Constants 



Retransmit Max 


15 


Maximum number of retries before giving up, for the 
"Transact" operation 


Burst Size 


4 


Number of retries per "burst" in the BackoffTransact 
operation 


Max Backoff 


300 


Maximum value of the backoff timer, in seconds (i.e., 
5 minutes) 


Load Protocol Type 


60-01 


Ethernet Protocol Type for Load and Dump protocol 


Console Protocol 
Type 


60-02 


Ethernet Protocol Type for Remote Console protocol 


Loopback Protocol 
Type 


90-00 


Ethernet Protocol Type for Loopback protocol 


Load Protocol ID 


08-00-2B-60-01 


IEEE 802.2 SNAP Protocol ID for Load and Dump 
protocol 


Console Protocol ID 


08-00-2B-60-02 


IEEE 802.2 SNAP Protocol ID for Remote Console 
protocol 


Loopback Protocol ID 


08-00-2B-90-00 


IEEE 802.2 SNAP Protocol ID for Loopback protocol 


Load Assistance 


AB-00-00-01-00-00 


Assistance multicast address for Load and Dump pro- 
tocol 


Console Multicast 


AB-00-00-02-00-00 


Multicast address for Remote Console protocol (for pe- 
riodic SYSID announcements) 


Loopback Assistance 


CF-00-00-00-00-00 


Assistance multicast address for Loopback protocol 


MOP Protocol ID 


01-01 


HDLC Protocol ID for MOP messages 



4.2.2 MOP module data type definitions 

The following are definitions of the data types used in this chapter. Since Modula-2-Plus 
does not have a "Sequence of type constructor (as in CMIP), the ARRAY OF constructor is used 
instead when needed. 

FROM System IMPORT Port, Timer, Time, Byte; 

FROM System IMPORT Random; (* Function to return a pseudo-random number 0<x<l *) 

FROM System IMPORT Wait; (* Procedure to wait for some amount of time *) 

FROM System IMPORT StartTimer, StopTimer, Expired; 

FROM Management IMPORT Binary AbsoluteTime, LocalEntityName, P4Name, P4Address, 

FileSpec, LANAddress, SAP Address; 
FROM Names IMPORT SimpleName, FullName; 
FROM CSMACD IMPORT FormatAndMux, LLCService; 

TYPE MOPVersion = (V3, V4, Unknown); 

CONST Infinite = « a time-out value to wait indefinitely »; 

FiveMinutes = « a time-out value equal to 5 minutes »; 

OneMinute = « a time-out value equal to 1 minute »; 

NullAddress = « the null (48 bits of zero) LANAddress »; 

LANTypes = { CSMACD, FDDI }; (* The set of Circuit Data Link types that are LANs *) 

LLCTEST = 0E3H; (* LLC Ctrl field code for TEST message *) 
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LLCXID = OAFH; 



(* LLC Ctrl field code for XID message *) 



TYPE Buffer = RECORD 

LANFormat: Format AndMux; 

Destination, Source: LANAddress; 

Length: INTEGER; 

Data: ARRAY [0..1ength-l] OF Byte 
END; 



(* LLC format and SAP *) 
(* LAN address fields *) 



TYPE Circuit = RECORD 

Name: SimpleName; 

DataLink: CircuitType; 

LinkName: LocalEntityName; 

DataLinkAddress: LANAddress; 

SDUSize: INTEGER; 

RetransmitTimer: Integer; 

KnownClientsOnly: Boolean; 

CircUID: UID.UID; 

CreateTime: Binary AbsoluteTime; 

Functions: Funtype; 

ConsoleUser: LANAddress; 

ReservationTimer: Timer; 

ConsoleSeq: INTEGER; 

LoadRequestsCompleted, UnrecognizedLoadClients, 
FailedLoadRequests , DumpRequestsCompleted , 
UnrecognizedDumpRequests, FailedDumpRequests: Counter 

mopport, loopport, LLCport: POINTER TO Port; (* Data link ports *) 
END; 



(* Identifier of this Circuit entity *) 
(* Type of data link *) 
(* Name of data link entity used *) 
(* This circuit's LAN address *) 
(* Datalink SDU size (MOP PDU size) 1 *) 

(* TRUE if only serving registered clients *) 

(* Creation time of this Circuit entity *) 
(* Enabled MOP functions *) 
(* Console user — if Console Carrier supported *) 
(* Console reservation timer — if C.C. supported *) 
(* Console Command sequence number *) 



TYPE Client = RECORD 
Name: SimpleName; 
CircPtr: POINTER TO Circuit; 
Addresses: SET OF LANAddress; 
DevTypes: SET OF DevType; 
SecondaryLoader, Tertiary Loader, 
Systemlmage, Diagnosticlmage, 
Managementlmage, ScriptFile: ARRAY 

( 

PhaselVHostName: P4Name; 
PhaselVHostAddress: P4Address; 
PhaselVClientName: P4Name; 
PhaselVClientAddress: P4Address; 
DumpFile: ARRAY OF FileSpec; 
Dump Address: INTEGER; 
Verification: OctetString; 
END; 



* Identifier of this client entity *) 

* Circuit used for this client 2 *) 

* Set of client data link addresses *) 

* Set of client device types *) 



OF FileSpec; 

* Actually, SEQUENCE *) 

* Four MOP V3 style parameter values *) 



(* Actually, SEQUENCE OF FileSpec *) 



TYPE Operation = RECORD 
Name: SimpleName; 
Addresses: SET OF LANAddress; 
Address: LANAddress; 
ClientName, CircName: SimpleName; 
CircPtr: POINTER TO Circuit; 



(* Identifier of this Operation entity *) 
(* Set of client data link addresses to try *) 
(* Address of remote station, if on LAN *) 
(* Name of Client and Circuit to use *) 
(* Circuit being used for this operation *) 



In data links where the maximum SDU sizes differ for transmit and receive, the smaller of the two values is used. 

The POINTER type is used here for descriptive convenience in the pseudocode. Note that the network manage- 
ment interface uses a SimpleName to refer to the Circuit; this allows Client and Circuit entities to be created in 
any order. 



4.2.2: MOP module data type definitions 



ClientPtr: POINTER TO Client; 
Version: MOPVersion; 
Timeout: Timer; 
CASE Op: OpType OF 
LoopRequester: 

AssistantSystem: SimpleName; (* Name of assistant (i.e., of its Client entity) *) 
AssistantAddresses: SET OF LANAddress; (* Set of assistant data link addresses to try *) 
AsisstantAddress: LANAddress; (* Selected data link address of assistant *) 



(* Client entity for this operation, if known *) 
(* Protocol version used by target *) 
(* Receive timer for this operation *) 
(* Operation being performed *) 



(* Type of assistance to use, if any *) 

(* Number of messages and length of each *) 

(* Byte value to load buffer with *) 

(* Nothing special *) 

(* For "Boot" directive *) 

(* Boot verification string ("password") *) 

(* Device name, if booting "specified device" 



AssistanceType: HelpType; 

Count, Length: INTEGER; 

Data: [0..255] I 
LoopServer: I 
ConsoleRequester: 

Verification: OctetString; 

Device: String; 

SoftwarelD, 

ScriptID: SoftwarelD I 
ConsoleServer: I 
LoadRequester: 

ProgramType: ProgType; 

Sequence: [0..255] I 
LoadServer: 

ProgramType: ProgType; 

SecondaryLoader, TertiaryLoader, 
Systemlmage, Diagnosticlmage, 
Managementlmage, ScriptFile: ARRAY OF FileSpec; 

(* Actually, SEQUENCE *) 

Verification: OctetString; (* Boot verification string ("password") *) 

SDUSize: Integer I (* MOP receive buffer size supported by station *) 

DumpRequester: I (* Nothing specific to dump client *) 

DumpServer: 

DumpFile: ARRAY OF FileSpec; (* Actually, SEQUENCE *) 



(* Value to use for Software ID of System and Script *) 
(* Nothing special *) 

(* Type of program being loaded *) 
(* Next load sequence number wanted *) 

(* Type of program requested by client *) 



DumpAddress: INTEGER; 

DumpCount: INTEGER; 

SDUSize: Integer I 
ConfigurationMonitor: I 
TestRequester: 

Count, Length: INTEGER; 

Data: [0..255]; 

SAP: SAPAddress I 
QueryRequester: 

SAP: SAPAddress 

END 
END; 



(* Address to dump next *) 

(* Amount left to dump (memory size) *) 

(* MOP receive buffer size supported by station *) 

(* Nothing specific to the configuration monitor *) 

(* Number of messages and length of each *) 

(* Byte value to load buffer with *) 

(* Destination SAP address to send to *) 

(* Destination SAP address to send to *) 



TYPE Station = RECORD 
Name: SimpleName; 
LastReport: Binary AbsoluteTime; 
Version: MOPVersion; 
Functions: SIDFunType; 
ConsoleUser: LANAddress; 
ReservationTimer, CommandSize, 

ResponseSize: INTEGER 
HardwareAddress: LANAddress; 
Device: DevType; 
DataLink: CircuitType; 
DSDUSize: Integer; 
NodeName: FullName; 



(* Identifier of this Station entity *) 

(* Time last heard from station *) 

(* Version of the station *) 

(* Supported functions *) 

(* Console user, or null address if none *) 



(* ROM Address for the station *) 
(* Device type of the station *) 
(* Type of data link *) 

(* MOP receive buffer size supported by station *) 
(* Name of the node, if known *) 
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NodelD: LANAddress; (* Node ID of station, if known *) 

CircPtr: POINTER TO Circuit; (* Circuit to which this Station record applies *) 

END; 

4.2.3 Message type definitions 

CONST MemLoadTA = 0; DumpComplete = 1; 
MemLoad = 2; Assistance = 3; 

RequestDump = 4; RequestID = 5; Boot = 6; SysID = 7; 
RequestProgram = 8; RequestCounters = 9; 
RequestLoad =10; CSMACDCounters = 11; 
RequestDumpService = 12; ReserveConsole = 13; 
DumpData =14; ReleaseConsole =15; 
ConsoleCommand =17; ConsoleResponse = 19; 
ParameterLoad = 20; OtherCounters = 21; 

LoopData = 24; LoopedData = 26; (* These two codes are for point to point circuits *) 

Reply = 1 ; ForwardData = 2; (* These two codes are for LAN loop protocol *) 

4.3 Use of the Client database 

Client database records contain parameters that MOP will use to satisfy requests related to 
a particular client. In general, request parameters can be supplied with the request. In the 
case of requests that are management directives, it is possible to supply all the needed parame- 
ters as directive arguments. In the case of requests that arrive via MOP protocol messages 
(e.g., Dump requests) the protocol message may not be able to encode all the necessary informa- 
tion. In either case, the requester may omit some of the parameters; such omitted parameters 
are filled in from the client database. 

Management directives may refer to a Client by name. In that case, the Client subentity 
with the supplied name is looked up, and its attributes are used as defaults for the directive 
parameters. Any parameters explicitly supplied with the directive override the defaults from 
the Client entry. 

If a management directive does not specify a Client name, no reference to the Client data- 
base is made and all required parameters must be included with the directive. 

Dump protocol requests always require a search of the Client database; Load protocol re- 
quests also require a search, unless the request includes a Software ID string and the Circuit 
attribute Known Clients Only is False. This is a search by circuit (see Section 4.18.3). If a 
matching Client entry is found, its parameters are used as defaults for the processing of the 
request. A Software ID string in a Request Program message, if present, overrides the file 
names in the client entry. If no entry is found, the result depends on the request: 

• A Dump request from an unknown client generates an Unrecognized Dump Client event, 
and is otherwise ignored. 

• For a Load request, the result also depends on the Known Clients Only attribute of the 
Circuit: 

If Known Clients Only is True, then a Load request from an unknown client gener- 
ates an Unrecognized Load Client event, and is otherwise ignored. 

Otherwise, if the Request Program message contains a Software ID string, the 
load server maps that string to a file name and attempts to open the file. If the 
open fails due to "File not found", this generates an Unrecognized Load Client 
event, and the load request is ignored. 



4.4: Processing of management directives 
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Otherwise (no Software ID string included in the Request Program message), this 
generates an Unrecognized Load Client event, and the load request is ignored. 

4.4 Processing of management directives 

This section defines the operation of the action directives which are invoked via the manage- 
ment interface defined in Chapter 3. 

In the algorithms below, directive parameters that are not supplied with the directive are 
defaulted from the Client database, if a Client name was supplied with the directive. If the 
Client name supplied with the directive does not match the name of an entry in the Client data- 
base, the exception UnrecognizedClient is generated. 

4.4.1 Loop directive 

The Loop directive is processed as follows: 

• Get defaulted Circuit and Address from the Client database, if a Client name was given. 

• Get defaulted Assistant Address from the Client database, if an Assistant Name was 
given. 

• On a LAN, if assistance was specified, select an assistant address by trying a direct loop 
to each of the assistant addresses. (If no specific assistant was specified, the loop is 
done to the Loopback Assistance multicast address.) The source address from the first 
received reply is the assistant address. 

• Perform the Loop exchange Count times. If the response has the wrong data, or the ex- 
change times out, abort the Loop operation. 

Special case: if the first exchange times out on a LAN, try the next target address. If all 
addresses have been tried, switch to the other MOP version format, and repeat the en- 
tire process (including assistant selection). If both versions time out for all addresses, 
the Loop fails with a Timeout error. 

Since the purpose of a Loop operation is to look for network problems, all the re- 
quest/response exchanges are done as single attempts, not with the usual "Transact" multiple 
retries. This ensures that intermittent errors are not masked. 

PROCEDURE DLI.Loop (clientsn, circuitsn: Names .SimpleName; target: LANAddress; 
assistantsn: Names .SimpleName; assistant: LANAddress; help: HelpType; 
loopcount, looplength: INTEGER; loopdata: INTEGER) 
RAISES {InvalidResponse, InsufficientResources, UnrecognizedCircuit, DataLinkError, 
UnrecognizedClient, RequiredArgumentOmitted, 

UnrecognizedAssistant, InvalidAssistant, In valid ArgumentValue, Timeout); 
VAR op: POINTER TO Operation; 

assistantptr: POINTER TO Client; 

buff: POINTER TO Buffer; 
BEGIN 

DLIAlloc (op, buff); (* Allocate necessary resources, if available *) 

TRY 

op A .Version := Unknown; 
op A .Op := LoopRequester; 

op A .Count := 1; op A Length := 40; op A .Data := 55H; (* Default values *) 
op A AssistantAddresses := { LoopbackAssistance }; (* Default value *) 
op\ClientPtr := NIL; (* Default value *) 

IF « clientsn supplied » 
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THEN 

op A .ClientName := clientsn; 

op A .ClientPtr := FindClientByName (op A .ClientName) 
END; 

op A .CircuitName := circuitsn; 
op A . Addresses := target; 
IF targetfO] = 1 
THEN 

RAISE (InvalidArgumentValue) 
END; 

op A AssistantSystem := assistantsn; 
op A .AssistantAddresses := assistant; 
IF assistant[0] = 1 
THEN 

RAISE (InvalidAssistant) 
END; 

op A AssistanceType := help; 
op A .Count := loopcount; 
op A .Length := looplength; 
op A .Data := loopdata; 
IF « circuitsn not supplied » 
THEN 

IFop A .ClientPtr*NIL 

THEN op A .CircuitName := op A .ClientPtr A .CircPtr A .Name 

END 
END; 

IF op A .CircuitName = "" 
THEN 

RAISE (RequiredArgumentOmitted) 
END; 

op A .CircPtr := FindCircuitByName (op A .CircuitName) 

IF « target not supplied » AND op A .CircPtr A .DataLink IN LANTypes 

THEN 

IFop A .ClientPtr*NIL 

THEN op A Addresses := op A .ClientPtr A Addresses; 
END; 

IF op A Addresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF op A .AssistantSystem * "" 
THEN 
TRY 

assistantptr := FindClientByName (op A .AssistantSystem) 
EXCEPT 

I UnrecognizedClient: RAISE (UnrecognizedAssistant) 
END; 

IF « assistant not supplied » 

THEN op A .AssistantAddresses := assistantptr A .Addresses; 

IF op A .AssistantAddresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (InvalidAssistant) 
END 
END; 

IF op A .CircPtr A .DataLink IN LANTypes 
THEN 

LANLoopRequester (op, buff) 
ELSE 

PTPLoopRequester (op, buff) 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* Multicast bit set in supplied target address? *) 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* Multicast bit set in supplied assistant address? *) 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* if supplied as directive argument *) 



4.4.2: Load directive 
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END 
FINALLY 

DLLFree (op, buff) 
END 
END DLLLoop; 

4.4.2 Load directive 

The Load directive is processed as follows: 

• Get defaulted parameters from the Client database, if a Client name was given. 

• Send Boot messages to the target. For a point to point circuit, one message is sent. For 
a LAN, two messages are sent to each address, one in each version format. The mes- 
sages have Control = 1, indicating "Load server = requesting system". This instructs 
the target to send its Request Program message back to the node sending the Boot mes- 
sages. 

• Wait for a Request Program message from the target. On a LAN, the Request Program 
may come from any of the target addresses, in either version format. The recommended 
timeout is 60 seconds. 

• If a Request Program message is received, proceed with load service requested by that 
message. 

Note: if a System Image and/or Script File argument was included in the directive, that 
file name overrides any Software ID string in a Request Program message for the corre- 
sponding Program Type.. 

PROCEDURE DLI.Load (clientsn, circuitsn: Names .SimpleName; target: LANAddress; 
loadfile, script, management, secondary, tertiary: FileSpec; ver: Octetstring) 
RAISES {InsufficientResources, UnrecognizedCircuit, DataLinkError, UnrecognizedClient, 
RequiredArgumentOmitted, ProtocolError, Invalid ArgumentValue, Timeout}; 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 
BEGIN 

DLIAlloc (op, buff); (* Allocate necessary resources, if available *) 

TRY 

op A . Version := Unknown; 
op A .Op := LoadServer; 

op A .ClientName := clientsn; (* if supplied as directive argument *) 

op A .CircuitName := circuitsn; (* if supplied as directive argument *) 

op A Addresses := target; (* if supplied as directive argument *) 

IF target[0] = 1 (* Multicast bit set in supplied target address? *) 

THEN 

RAISE (InvalidArgumentValue) 
END; 

op A .SystemImage := loadfile; (* if supplied as directive argument *) 

op A .DiagnosticImage := op A .SystemImage; (* Use it also if target asks for diagnostic image *) 
op A .ScriptFile := script; (* if supplied as directive argument *) 

op A .ManagementImage := management; (* if supplied as directive argument *) 

op A .SecondaryLoader := secondary; (* if supplied as directive argument *) 

op A .TertiaryLoader := tertiary; (* if supplied as directive argument *) 

op A . Verification := ver; (* if supplied as directive argument *) 

op\ClientPtr := NIL; (* Default value *) 

IF « clientsn supplied » 
THEN 

op A .ClientName := clientsn; 
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op A .ClientPtr := FindClientByName (op A .ClientName) 
END; 

IF « circuitsn not supplied » 
THEN 

IFop A .ClientPtr*NIL 

THEN op\CircuitName := op A .ClientPtr A .CircPtr A .Name 
END 
END; 

IF op\CircuitName = "" 
THEN 

RAISE (RequiredArgumentOmitted) 
END; 

op A .CircPtr := FindCircuitByName (op A .CircuitName) 

IF « target not supplied » AND op A .CircPtr A .DataLink IN LANTypes 

THEN 

IFop A .ClientPtr*NIL 

THEN op A Addresses := op A .ClientPtr A Addresses; 
END; 

IF op A Addresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF « loadfile not supplied » 
THEN 

IFop A .ClientPtr*NIL 

THEN op A .SystemImage := op A .ClientPtr A .SystemImage 
op A .DiagnosticImage := op A .ClientPtr A .SystemImage 
END; 

IF op A .SystemImage = { } (* Check for no System Image in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF « script not supplied » AND op A .ClientPtr * NIL 
THEN op\ScriptFile := op A .ClientPtr A .ScriptFile 
END; 

IF « management not supplied » AND op A .ClientPtr * NIL 

THEN op A .ManagementImage := op A .ClientPtr A .ManagementImage 

END; 

IF « secondary not supplied » AND op A .ClientPtr * NIL 

THEN op A .SecondaryLoader := op A .ClientPtr A . Secondary Loader 

END; 

IF « tertiary not supplied » AND op A .ClientPtr * NIL 
THEN op A . Tertiary Loader := op A .ClientPtr A . Tertiary Loader 
END; 

IF « ver not supplied » AND op A .ClientPtr * NIL 
THEN op A .Verification := op A .ClientPtr A .Verification 
END; 

DLI.SendBoot (op, buff, 1); (* Send Boot msg with Boot Server = Requesting System *) 

DLI.Receive (op, buff, OneMinute, Unknown); (* Wait 1 minute for a Request Program message *) 
op A .ProgramType := buff A .Data[3]; (* get program type from Request Program message *) 
IF op A .ProgramType = System 
THEN 

IF « Request Program message indicates request for Diagnostic Image » 
THEN op A .ProgramType := Diagnostic 
END 
END 

IF « Data Link Buffer Size present in message » 

THEN op A .SDUSize := « Data Link Buffer Size from message » 



4.4.3: Boot directive 
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ELSE op A .SDUSize := 262 
END; 

DLI.PerformLoad (op, buff) 

(* Note that Software ID string is overridden by directive arguments if specified *) 
FINALLY 

DLLFree (op, buff) 
END 
END DLILoad; 



4.4.3 Boot directive 



The Boot directive is processed as follows: 

• Get defaulted parameters from the Client database, if a Client name was given. 

• Send Boot messages to the target. For a point to point circuit, one message is sent. For 
a LAN, two messages are sent to each address, one in each version format. The mes- 
sages have Control = 2, indicating "Load device = specified device" if the Device argu- 
ment was present on the directive, and Control = 0, indicating "Load server = system 
default" otherwise. 



PROCEDURE DLI.Boot (clientsn, circuitsn: Names.SimpleName; target: LANAddress; 
ver: Octetstring; dev, swid, scrid: SoftwarelD) 

RAISES {InsufficientResources, UnrecognizedCircuit, DataLinkError, 

UnrecognizedClient, Required ArgumentOmitted, Invalid ArgumentValue); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

Ctrl: INTEGER; 
BEGIN 

DLI Alloc (op, buff); 

TRY 

op A .Version := Unknown; 



(* Allocate necessary resources, if available *) 



op A .Op := ConsoleRequester; 
op A .ClientName := clientsn; 
op A .CircuitName := circuitsn; 
op A Addresses := target; 
IF target[0] = 1 
THEN 

RAISE (InvalidArgumentValue) 
END; 

op A . Verification := ver; 

op A .Device := dev; 

IF « dev argument supplied » 

THEN Ctrl := 2 

ELSE Ctrl := 

END; 

op A .SoftwareID := swid; 



op A .ScriptID := scrid; 
IF NOT (DLI.ValidID (swid) AND DLI.ValidID (scrid)) 
THEN RAISE (InvalidArgumentValue) 
END; 

IF « circuitsn not supplied » 
THEN 

IF op A .ClientPtr * NIL 

THEN op\CircuitName := op A .ClientPtr A .CircPtr A .Name 
END 
END; 

IF op\CircuitName = "" 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* Multicast bit set in supplied target address? *) 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 

(* Control = "Boot device = specified device" * 
(* Control = "Boot server = system default" *) 

(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
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THEN 

RAISE (RequiredArgumentOmitted) 
END; 

op A .CircPtr := FindCircuitByName (op A .CircuitName) 

IF « target not supplied » AND op A .CircPtr A .DataLink IN LANTypes 

THEN 

IF op A .ClientPtr * NIL 

THEN op A Addresses := op A .ClientPtr A Addresses; 
END; 

IF op A Addresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF « ver not supplied » AND op A .ClientPtr * NIL 
THEN op A .Verification := op A .ClientPtr A .Verification 
END; 

IF LENGTH(op A Verification) > 8 
THEN RAISE (InvalidArgumentValue) 
END; 

DLI.SendBoot (op, buff, Ctrl) (* Send Boot messages *) 

FINALLY 

DLI.Free (op, buff) 
END 
END DLI .Boot; 

PROCEDURE DLI.ValidID (id: SoftwarelD) : Boolean 
BEGIN 

« return TRUE if id meets the Software ID validity criteria described in Section 5.5.1 » 
END DLI.ValidID; 

PROCEDURE DLI.SendBoot (op: POINTER TO Operation; buff: POINTER TO Buffer; Ctrl: INTEGER); 

VAR target: LAN Address; 

BEGIN 

buff\Data[0] := Boot; 

« store op A . Verification in buffer data bytes 1 through 8, pad with trailing bytes if necessary »; 
buff A .Data[9] := 0; (* System processor *) 

buff A .Data[10] := Ctrl; (* Control byte as specified *) 

IF Ctrl = 2 

THEN « store op A .Device in buffer starting at byte 1 1 » 
END; 

IF op A . SoftwarelD = "" 

THEN « store byte of in buffer » (* No software ID string supplied *) 

ELSE « store op A .SoftwarelD string in buffer » 

END; 

IF op A .ScriptID * "" 

THEN « store op A .ScriptID string in buffer » 
END; 

IF op A .CircPtr A .DataLink IN LANTypes 
THEN 
LOOP 

IF op A Addresses = { } 

THEN EXIT 

END; (* Done if no more addresses *) 

target := « select and remove an address from op A .Addresses »; 
buff A .Destination := target; 

DLI.Send (op, buff, V4); (*Send V4 format Boot message *) 

IFop A .ScriptID= "" 

THEN (* Skip V3 if asking for a V4-only function *) 



4.4.4: Test directive 
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DLI.Send (op, buff, V3) (*Send V3 format Boot message *) 
END 
END 
ELSE 

DLI.Send (op, buff, V4); (*Send Boot message on point to point link *) 

END 

END DLI.SendBoot; 



4.4.4 Test directive 



The Test directive is processed as follows: 

• Get defaulted parameters from the Client database, if a Client name was given. 

• Select a suitable Source SAP address (see Section 4.18.5 below). 

• Perform the TEST exchange Count times. If the response has the wrong data, or the 
exchange times out, abort the Test operation. 

Special case: if the first exchange times out, try the next target address. If all addresses 
time out for all addresses, the Test fails with a Timeout error. 

Since the purpose of a Test operation is to look for network problems, all the re- 
quest/response exchanges are done as single attempts, not with the usual "Transact" multiple 
retries. This ensures that intermittent errors are not masked. 



PROCEDURE DLI.Test (clientsn, circuitsn: Names .SimpleName; target: LANAddress; 
loopcount, looplength: INTEGER; loopdata: INTEGER; dsap: SAP Address) 
RAISES {InvalidResponse, InsufficientResources, UnrecognizedCircuit, DataLinkError, 
UnrecognizedClient, RequiredArgumentOmitted, DirectiveNotSupported, 
In valid Argument Value, Timeout); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 
BEGIN 

DLI Alloc (op, buff); 
TRY 



(* Allocate necessary resources, if available *) 



op A .Version := Unknown; 

op A .Op := TestRequester; 

op A .Count := 1; op A Length := 40; 

op A .Data := 55H; op A .SAP := 0; 

op A .ClientName := clientsn; 

op A .CircuitName := circuitsn; 

op A Addresses := target; 

IF target[0] = 1 

THEN 

RAISE (InvalidArgumentValue) 
END; 

op A .Count := loopcount; 
op A Length := looplength; 
op A .Data := loopdata; 
op A .SAP := dsap; 
IFop A .SAP[0] = 1 
THEN 

RAISE (InvalidArgumentValue) 
END; 

IF « circuitsn not supplied » 
THEN 

IF op A .ClientPtr * NIL 



(* Default values *) 

(* Default values *) 

(* if supplied as directive argument *) 

(* if supplied as directive argument *) 

(* if supplied as directive argument *) 

(* Multicast bit set in supplied target address? *) 



(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* if supplied as directive argument *) 
(* if supplied as directive argument *) 

(* Group SAP is invalid *) 
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THEN op\CircuitName := op A .ClientPtr A .CircPtr\Name 
END 
END; 

IF op\CircuitName = "" 
THEN 

RAISE (RequiredArgumentOmitted) 
END; 

op A .CircPtr := FindCircuitByName (op A .CircuitName) 

IF « target not supplied » 

THEN 

IFop A .ClientPtr*NIL 

THEN op A .Addresses := op A .ClientPtr A Addresses; 
END; 

IF op A Addresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF op A .CircPtr A .DataLink IN LANTypes 
THEN 

LAN.TestRequester (op, buff) 
ELSE 

RAISE (DirectiveNotSupported) 
END 
FINALLY 

DLI.Free (op, buff) 
END 
END DLI Test; 

4.4.5 Query directive 

The Test directive is processed as follows: 

• Get defaulted parameters from the Client database, if a Client name was given. 

• Select a suitable Source SAP address (see Section 4.18.5 below). 

• Perform the XID exchange. If it times out, try the next target address until all have 
been tried. If all addresses time out, the Query fails with a Timeout error. 

PROCEDURE DLI.Query (clientsn, circuitsn: Names .SimpleName; target: LANAddress; 

dsap: SAP Address; VAR LLCTypes; SET OF INTEGER; VAR Window: INTEGER) 
RAISES {InvalidResponse, InsufficientResources, UnrecognizedCircuit, DataLinkError, 
UnrecognizedClient , RequiredArgumentOmitted , DirectiveNotSupported , 
Invalid ArgumentValue, Timeout); 
VAR op: POINTER TO Operation; 
buff: POINTER TO Buffer; 



BEGIN 



DLI Alloc (op, buff); 
TRY 



(* 



Allocate necessary resources, if available *) 



op A .Version := Unknown; 
op A .Op := Query Requester; 
op A .SAP:=0; 
op A .ClientName := clientsn; 
op A .CircuitName := circuitsn; 
op A Addresses := target; 
IF target[0] = 1 
THEN 



(* 
(* 
(* 
(* 
(* 



Default value *) 



if supplied as directive argument *) 
if supplied as directive argument *) 
if supplied as directive argument *) 



Multicast bit set in supplied target address? *) 



RAISE (InvalidArgumentValue) 



4.5: Downline load algorithms 
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END; 

op A .SAP := dsap; (* if supplied as directive argument *) 

IFop\SAP[0] = 1 

THEN (* Group SAP is invalid *) 

RAISE (InvalidArgumentValue) 
END; 

IF « circuitsn not supplied » 
THEN 

IF op A .ClientPtr * NIL 

THEN op A .CircuitName := op A .ClientPtr A .CircPtr A .Name 
END 
END; 

IF op A .CircuitName = "" 
THEN 

RAISE (RequiredArgumentOmitted) 
END; 

op A .CircPtr := FindCircuitByName (op A .CircuitName) 

IF « target not supplied » 

THEN 

IF op\ClientPtr * NIL 

THEN op A Addresses := op A .ClientPtr A Addresses; 
END; 

IF op A Addresses = { } (* Check for no addresses in Client database *) 

THEN RAISE (RequiredArgumentOmitted) 
END 
END; 

IF op A .CircPtr\DataLink IN LANTypes 
THEN 

LAN .Query Requester (op, buff, LLCTypes, Window) 
ELSE 

RAISE (DirectiveNotSupported) 
END 
FINALLY 

DLLFree (op, buff) 
END 
END DLI .Query; 



4.5 Downline load algorithms 

This section defines the major algorithms used for down line load. 

4.5.1 Downline load client 

This section shows the Load Client algorithm. 

In the case of a LAN load, the server address is normally not known. In that case, the first 
step is a Request Program message to the Load Assistance multicast address. These initial re- 
quests are sent both in V4 and V3 format, unless the request is one that is defined only in MOP 
V4. The first server that responds is used as the server for the rest of the load. However, if the 
load was initiated by a Boot message with Control = 1 ("Load server = Requesting system"), or if 
for some other reason the client knows which server should be used, then that server is used for 
the load and the multicast to the Load Assistance address is skipped. 

The algorithm shows a timeout of one minute on each transaction once the load is underway. 
The load client does not have to do retransmissions at that stage, since the load server does 
them, but it does need some sort of timeout to handle the case where the network is partitioned 
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or the load server has crashed. The load server does 15 retries at (by default) 4 second inter- 
vals, so a one minute load client timeout is appropriate. 

There are some special rules relating to the Secondary Loader. This fits in a single Memory 
Data message. A request for a Secondary Loader is answered with that data, not with an Assis- 
tance Volunteer message. To ensure that subsequent load steps (for example Tertiary Loader 
or Operating System) do not terminate prematurely due to receiving another copy of a secon- 
dary loader, the load client ignores any Memory Data with Transfer Address messages that con- 
tain load data whenever it is loading anything other than Secondary Loader. Similarly, the 
load client ignores any Memory Data with Transfer address messages that contain no data 
when it is loading a Secondary Loader. The load sequences for other program types terminate 
either with a Parameter Load message or with a Memory Load with Transfer Address message 
that contains no data. 

The amount of memory data in each Memory Load message may vary; the client must not 
assume that it will receive a full size message each time. The memory data may be null, for 
example if the load server does not have the next segment of memory data available yet but 
wants to keep the client from timing out. In all cases, the client transfers the memory data in 
the message (if any) and responds with a request for the next higher sequence number. 

PROCEDURE DLLLoadClient (circ: POINTER TO Circuit; server: LANAddress; 
prog: ProgType; swid, scrid: SoftwarelD) 

RAISES {InsufficientResources, DataLinkError, Timeout} 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

msgtyp, seq, rseq, ldaddr: INTEGER; 
BEGIN 

DLIAlloc (op, buff); (* Allocate necessary resources, if available *) 

op A .CircPtr := circ; 

op A .Op := LoadClient; 

op A . Version := Unknown; 

op A . Address := server; 

op A .ProgramType := prog; 

IF prog = CMIPScript 

THEN op A Version := V4 (* CMIP Script is a V4 only function *) 

END; 

TRY 

IF op A .CircPtr A .DataLink IN LANTypes AND server = NullAddress 
THEN (* LAN and server not selected yet *) 

DLI.BuildReqProg (op, buff, prog, swid, scrid); 

buff A .Destination := LoadAssistance; 

DLI.BackoffTransact (op, buff, buff); 

op A Address := buff A .Source; (* Whoever answers is our server *) 

IF prog = SecondaryLoader (* For Secondary the answer is the data *) 

THEN 

IF buff A .Data[0] * MemLoadTA (* If it isn't the right message type *) 
OR buff A .Length < 10 (* ...or message has null data *) 

THEN op A .Address := NullAddress; (* No server yet after all *) 
« quietly ignore this message and keep requesting » 

END 

ELSE (* for others, ask selected server again *) 

DLI.BuildReqProg (op, buff, prog, swid, scrid); 

buff A .Destination := op A Address; 

DLI Transact (op, buff, buff); 
END 

ELSE (* We know the server we want, talk to it *) 

DLI.BuildReqProg (op, buff, prog, swid, scrid); 
buff A .Destination := op A .Address; 
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DLLBackoffTransact (op, buff, buff); 
END 

seq := 0; (* Start with sequence number zero *) 

(* Note: on entry to the loop we have just received the first Memory Load message *) 

LOOP 

msgtyp = buff A .Data[0]; 

IF msgtyp = MemLoadTA AND buff A .Length > 10 AND prog * SecondaryLoader 

THEN « quietly ignore this message » 

END; 

rseq := buff A .Data[l]; (* Get sequence number from received message *) 

IF rseq = seq (* If it matches the sequence number we want *) 

THEN 

ldaddr := DLI.GetLong (buff, 2); (* Get memory address to load *) 

IF msgtyp = ParameterLoad 

THEN « store the received parameters » 

ELSEIF (msgtyp = MemLoad AND buff A .Length > 6) 

OR (msgtyp = MemLoadTA AND buff A .Length > 10) 
THEN 

IF prog IN { Management, CMIPScript } AND ldaddr = 
THEN « begin a new management file or CMIP script record » 
END; 

« store data at specified ldaddr » 
END; 

seq := (seq + 1) MOD 256; (* Look for the next consecutive sequence number *) 

IF msgtyp IN { MemLoadTA, ParameterLoad } 

THEN 

EXIT (* Leave the loop, done with the load *) 

END 
END; 

DLI.BuildReqLoad (buff, seq); 

DLI.ReqResp (op, buff, buff, OneMinute, op A . Version); 
END; 

IF msgtyp = ParameterLoad (* If system or diagnostic image load *) 

THEN 

DLI.BuildReqLoad (buff, seq); 

DLI.Send (op, buff, op A .Version); (*Send one more request to ACK the last message *) 

END; 
FINALLY 

DLLFree (op, buff) 
END 

END DLLLoadClient; 

The procedures below show how the Load protocol messages are constructed. Note that the 
Format Version byte (third byte) of the Request Program message should be set to reflect what 
protocol version is being sent; the V3 requests have the value 1 in Format Version, and the V4 
requests have the value 4. 

PROCEDURE DLLBuildReqProg (op: POINTER TO Operation; 

buff: POINTER TO Buffer; prog: ProgType; swid, scrid: SoftwarelD); 
VAR idlen: INTEGER; 

idstring: SoftwarelD; 
BEGIN 

buff A .Data[0] := RequestProgram; 

buff A .Data[l] := « Device Type code of data link being used »; 

buff A .Data[2] := « Format Version, see above »; 

IF prog = Diagnostic 

THEN buff\Data[3] := System 

ELSE buff\Data[3] := prog (* Program Type *) 
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END; 

IF prog = System THEN idstring := swid 

ELSEIF prog = CMIPScript THEN idstring := scrid 

ELSE idstring := "" 

END; 

idlen := LENGTH (idstring); 

IF idlen > 

THEN 

buff\Data[4] := idlen; 

« store idstring starting at buff A .Data[5] » 
ELSEIF prog = System 

THEN buff\Data[4] := -1 (* Standard operating system *) 

ELSEIF prog = Diagnostic 

THEN buff\Data[4] := -2 (* Diagnostic system *) 

ELSE buff\Data[4] := (* No ID string *) 

END; 

buff A .Data[5 + idlen] := (* System processor *) 

(* Store TLV entry for Data Link Buffer Size *) 
DLLPutlnteger (buff, 6 + idlen, 401); 
DLLPutlnteger (buff, 8 + idlen, 2); 
DLLPutlnteger (buff, 10 + idlen, op A .CircPtr A .SDUSize); 
buff A .Length := 12 + idlen 
END DLLBuildReqProg; 



PROCEDURE DLLBuildReqLoad (buff: POINTER TO Buffer; seq: INTEGER); 
BEGIN 

buff\Data[0] := RequestLoad; 

buff A .Data[l] := seq; (* Next sequence number we want *) 

buff\Data[2] := 0; (* obsolete/reserved *) 

buff A .Length := 3 
END DLLBuildReqLoad; 



4.5.2 Downline load server 



The following sections show the load server algorithms. 

4.5.2.1 Downline load server listener 



This section shows the operation of the load server listener. It listens for load requests initi- 
ated by load clients, and uses the Request Program message and information in the Client data- 
base to decide whether and how to process the request. This process is active only if Load serv- 
ice is enabled for the circuit. The outline of the algorithm is as follows: 

• A client database lookup is performed first. 

First look for a client entry by circuit and (if a LAN) data link address. 

If no match is found and this is a LAN, look for a client entry by circuit and de- 
vice type. 

• If Known Clients Only is False, and a syntactically valid Software ID string was included 
in the request, then the load can proceed whether or not an entry is found in the client 
lookup. Otherwise, if no entry is found, this is an Unrecognized Client. 

If an entry is found, the file names it specifies are used as the load files for this load 
operation unless the load client supplied a Software ID string. 
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• If the request specified a Software ID string, map the ID string to a file name and see if 
that file exists. If not, this is a File Open Error if a client entry was found previously, 
and an Unrecognized Client otherwise. (Note that the Software ID string overrides cli- 
ent database load file information.) 

• If this is a LAN and the original request was addressed to the Load Assistance 
multicast address, send an Assistance Volunteer message and wait for a directed Re- 
quest Program message (indicating this node was selected). If none is received, quietly 
go back to listening for other requests. (This condition is not an error and no event 
should be logged in this case.) 

Note: as shown here the Assistance Volunteer is sent before any files are opened, except 
where Software ID strings are involved. An implementation may instead open files 
first, and not volunteer until it has sucessfully done the open. This will avoid volunteer- 
ing when the client database points to non-existent or inaccessible files. 

The secondary loader is a special case: the entire secondary loader is sent in a single 
message. No Assistance Volunteer is sent in this case; the response to the Request Pro- 
gram message is simply a message containing the secondary loader. 

• Load the client according to the received request, with load file as determined above. 

PROCEDURE DLILoadServer (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

device: DevType; 

prog: ProgType; 

idstring: SoftwarelD; 

loadok: Boolean; (* True if we can load this client *) 

i: INTEGER; 
EXCEPTION Quit; 
BEGIN 

NEW (op); (* Get an Operation record *) 

op A .CircPtr := circ; 
op A .Op := LoadServer; 
LOOP 
TRY 

op A Address := NullAddress; (* We'll listen to any remote station address *) 

op A .Version := Unknown; (* Accept any version *) 

DLLReceive (op, buff, Infinite); (* Wait for a message, however long it takes *) 

IF buff\Data[l] = 31 (* Special case *) 

THEN 

device := 37 (* 37 is LQA, 31 is alternate code for LQA *) 

ELSE 

device := buff A .Data[l] (* Get requester's device type *) 

END 

IF buff A Length < 3 

THEN prog := SecondaryLoader (* Default if no program type in message *) 
ELSE prog := buff A .Data[3]; (* Get program type *) 

IF prog = System 

THEN 

IF « Request Program message indicates request for Diagnostic Image » 
THEN prog := Diagnostic 
END 
END 
END; 

op A .ProgramType := prog; 

idstring := « ID string from Request Program message, or null if no string supplied »; 
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IF NOT DLI.ValidID (idstring) 

THEN idstring := "" (* If supplied ID isn't valid, pretend none was supplied *) 

END; 

IF « Data Link Buffer Size present in message » 

THEN op A .SDUSize := « Data Link Buffer Size from message » 

ELSE op A .SDUSize := 262 

END; 

loadok := FALSE; 

op A .Client := DLI.FindClientByCircAddr (circ, buff A .Source); 
IF circ A .DataLink IN LANTypes AND op A .Client = NIL 
THEN 

op A .Client := DLI.FindClientByCircDev (circ, device) 
END; 

IFop\Client*NIL 
THEN 

loadok := TRUE; 

op A . Secondary Loader := op A .Client A .SecondaryLoader; 
op A . Tertiary Loader := op A .Client A . Tertiary Loader; 
op A .SystemImage := op A .Client A .SystemImage; 
op A .DiagnosticImage := op A .Client A .DiagnosticImage; 
op A .ManagementImage := op A .Client A .ManagementImage; 
op A .ScriptFile := op A .Client A .ScriptFile; 
IF idstring * " " 

THEN (* ID string supplied, override database filename *) 

loadok := DLI.MapIDString (op, idstring) 
END 

ELSEIF NOT KnownClientsOnly (* No client entry found *) 
IF idstring * " " 

THEN (* ID string supplied, map to filename *) 

loadok := DLI.MapIDString (op, idstring) 

END 
END; 
IF loadok 
THEN 

IF circ\DataLink IN LANTypes 

AND buff A .Destination[0] = 1 (* multicast request requires volunteer response *) 
AND op A .ProgramType * SecondaryLoader (* except secondary loaders *) 

THEN 

FOR i := 1 TO RetransmitMax 
DO 

LAN. Send Volunteer (op, buff); (* Volunteer to serve *) 

TRY 

DLI .Receive (op, buff, OneMinute); 
EXCEPT 

I Timeout: RAISE (Quit) 
END; 

« received Request Program message should be the same as the multicast request 
that initiated the lookup. If not, quit and report a Load Request Failed event, 
Reason = Protocol Error. » 

IF buff A .Destination[0] = 

THEN EXIT (* Request Program direct to us, carry on *) 

ELSEIF i = RetransmitMax 

THEN RAISE (Quit) (* Volunteer isn't being heard, quit *) 

END 
END 
END; 

DLI.PerformLoad (op,buff); (* Go perform the actual load with these parameters *) 
« report a Load Request Completed event » 
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ELSE 

IF op\Client = NIL 

THEN (* Couldn't load because no matching client entry *) 

« report an Unrecognized Load Client event » 
ELSE (* Couldn't load because of bad Software ID *) 

« report a Load Request Failed event, reason = File Open Error » 
END 
EXCEPT 

I Quit: (* Quit load attempt quietly *) 

I ELSE « report a Load Request Failed event, Reason as indicated by the exception » 

END; 

DLLReceiveDone (buff) 
END 

END DLILoadServer; 



PROCEDURE DLLMapIDString (op: POINTER TO Operation; idstring: SoftwarelD) : 
VAR filename: FileSpec; 

exists: Boolean; 
BEGIN 

filename := « map idstring to file name »; 
CASE op A .ProgramType OF 

Secondary Loader: 

Tertiary Loader: 

System: 

Diagnostic: 

Management: 

ScriptFile: 
END; 

exists := « True if file named by filename exists »; 
RETURN (exists) 
END DLLMapIDString; 
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op A . Secondary Loader := filename I 
op A . Tertiary Loader := filename I 
op A .SystemImage := filename I 
op A .DiagnosticImage := filename I 
op A .ManagementImage := filename I 
op A .ScriptFile := filename 



PROCEDURE LAN.SendVolunteer (op: POINTER TO Operation, buff: POINTER TO Buffer); 
BEGIN 

buff A .Destination := op A Address; 
buff A Length := 1; 

buff A .Data[0] := AssistanceVolunteer; 
DLI.Send (op, buff, op A .Version) 
END LAN.SendVolunteer; 



4.5.2.2 Downline load data transfer phase 



This section shows the algorithm for the actual data transfer phase of the downline load 
process. 

This procedure is given as input an Operation record, which specifies the address and MOP 
version of the client, as well as a load file name or possibly sequence of file names. This infor- 
mation was determined either from management directive parameters (in the case of a Load 
directive) or from a Request Program message (in the case of a load initiated by a load client); 
in either case the Client database may have been used to supply additional information. 

The general flow of the load is 

• Attempt to open load file; try next in sequence if failure, until end of list or success. If 
failure, abort the load. 

• If program type is Secondary Loader, transfer the entire loader in a Memory Data with 
Transfer Address message. 



58 



Operation 



Otherwise, transfer the data in multiple messages: 

Send each piece of load data in a Memory Data message. Increment the load ad- 
dress by the amount sent. 

- If program type is Management Image or Script File, the data is organized in re- 
cords. Each new record begins in a new Memory Data message, and for each new 
record the load address is reset to zero. 

After all data was sent, a load of System Image or Diagnostic Image is terminated 
with a Parameter Load message. Other program types are terminated with a 
Memory Data with Transfer Address message that has no load data in it. For the 
Management Image or Script file, the transfer address is -1. 

• Once the load is complete, an implementation should wait for another Request Program 
message from the same client. In this way the server will handle a multi-step load 
without having to do multiple client database lookups. In the case of a load initiated by 
the Load directive, waiting for another request ensures that all the steps of a multi-step 
load are done in the context of that directive, i.e., with load parameters as supplied with 
the directive. 

The recommended timeout when waiting for another Request Program is 60 seconds. 

PROCEDURE DLLPerformLoad (op: POINTER TO Operation; buff; POINTER TO Buffer) 

RAISES { DataLinkError, Timeout, FileOpenError } 
VAR prog: ProgType; 

files: ARRAY OF FileSpec; 

ldaddr, segsiz, seq, rseq, maxdatasize: INTEGER; 
BEGIN 

CASE op\ProgramType OF 



Secondary Loader: 


files 


= op A . Secondary Loader 1 


Tertiary Loader: 


files 


= op A . Tertiary Loader 1 


System: 


files 


= op A .SystemImage 1 


Diagnostic: 


files 


= op A .DiagnosticImage 1 


Management: 


files 


= op A .ManagementImage 1 


ScriptFile: 


files 


= op A .ScriptFile 



END; 
LOOP 

IF files = { } 

THEN RAISE (FileOpenError) (* Ran out of files to try *) 

END; 

« select and remove a filespec from files »; 
TRY 

« open the selected filespec »; 

EXIT (* Got the file we wanted *) 

EXCEPT 

ELSE (* Keep going on any error *) 

END 
END; 
seq := 0; 

IF op A .Version = V3 

THEN (* Check and correct erroneous buffer size values *) 

IFop\SDUSize> 1498 

THEN op A .SDUSize := 1498 

ELSEIF op A .SDUSize = 1030 

THEN op A .SDUSize := 1010 

END 
END; 

IF op A .ProgramType = Secondary Loader 
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THEN 

maxdatasize := MIN (op\SDUSize, op\CircPtr A .SDUSize) - 10; 

(* Max image data in a Memory Load with TA message *) 

ELSE 

maxdatasize := MIN (op A .SDUSize, op A .CircPtr A .SDUSize) - 6; 

(* Max image data in a Memory Load message *) 

END; 

ldaddr := « base load address of image »; 
IF op A .ProgramType = Secondary Loader 
THEN 

« read entire secondary loader image, must fit in maxdatasize »; 
DLI.BuildMemLoadTA (op, buff, 0, ldaddr, « secondary loader data ») 
ELSE 

LOOP 

« read another segment of load data, < maxdatasize bytes long »; 
IF « no more data » 
THEN EXIT 
END; 

segsiz := « length of load data segment »; 

IF op A .ProgramType IN { Management, CMIPScript } 

AND « segment is the start of a new record » 
THEN ldaddr := 
END; 

DLI.BuildMemLoad (op, buff, seq, ldaddr, « load data segment »); 
LOOP 

DLI .Transact (op, buff, buff); 

IF buff A .Data[0] = RequestProgram (* Another RequestProgram from client? *) 

THEN « quietly ignore this message » 

ELSE 

rseq := buff A .Data[l]; (* Get sequence number requested by client *) 
IF rseq = ((seq + 1 ) MOD 256) 

THEN EXIT (* asking next segment, go on *) 

ELSEIF rseq * seq 

THEN « quietly ignore this message » 
END 
END 
END; 

seq := (seq + 1) MOD 256; 
ldaddr := ldaddr + segsiz; 
END; 

IF op A .ProgramType IN { System, Diagnostic } 
THEN DLI.BuildParameterLoad (op, buff, seq) 
ELSE DLI.BuildMemLoadTA (op, buff, seq, ldaddr, "") 
END 
END; 

(* Send the closing message of the load *) 
LOOP 
TRY 

DLI .Transact (op, buff, buff) 
EXCEPT 

I Timeout: EXIT (* Timeout means we're done but not an error here *) 

END; 

IF buff A .Data[0] = RequestProgram (* RequestProgram (for next load phase)? *) 
THEN EXIT (* done — and go process that request *) 

END; 

rseq := buff A .Data[l]; (* Get sequence number requested by client *) 

IF rseq = ((seq + 1) MOD 256) 

THEN EXIT (* asking next segment (ACK), done *) 
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ELSEIF rseq * seq 

THEN « quietly ignore this message » 
END 
END; 

IF buff A .Data[0] * RequestProgram (* If we didn't already receive the next Req Prog *) 

AND (op A .ProgramType IN { SecondaryLoader, TertiaryLoader } 

OR (op A .ProgramType IN { System, Diagnostic } 

AND (op A .ManagementImage OR op A .ScriptFile * { }))) 
THEN (* Another request from this client is expected *) 

« wait for another Request Program from this client » 
END; 

IF buff A .Data[0] = RequestProgram 
THEN 

« repeat to process new received Request Program » 
END 

END DLLPerformLoad; 

PROCEDURE DLLBuildMemLoad (op: POINTER TO Operation, buff: POINTER TO Buffer; 

seq, ldaddr: INTEGER; data: STRING); 
BEGIN 

buff A .Destination := op A .Address; 
buff\Data[0] := MemLoad; 
buff A .Data[l] := seq; 
DLI.PutLong (buff, 2, ldaddr); 
« move data into buffer starting at byte 6 »; 
buff A .Length := 6 + LENGTH(data) 
END DLLBuildMemLoad; 

PROCEDURE DLLBuildMemLoadTA (op: POINTER TO Operation, buff: POINTER TO Buffer; 

seq, ldaddr: INTEGER; data: STRING); 
BEGIN 

buff A .Destination := op A .Address; 

buff\Data[0] := MemLoadTA; 

buff\Data[l] := seq; 

DLI.PutLong (buff, 2, ldaddr); 

« move data into buffer starting at byte 6 »; 

IF op A .ProgramType IN { Management, CMIPScript } 

THEN DLI.PutLong (buff, 6 + LENGTH(data), -1) 

ELSE DLI.PutLong (buff, 6 + LENGTH(data), « transfer address from load file ») 
END; 

buff A Length := 10 + LENGTH(data) 
END DLLBuildMemLoadTA; 

PROCEDURE DLLBuildParameterLoad (op: POINTER TO Operation, buff: POINTER TO Buffer; 

seq: INTEGER); 
BEGIN 

buff A .Destination := op A .Address; 
buff A .Data[0] := ParameterLoad; 
buff\Data[l] := seq; 
IF op A .ClientPtr*NIL 
THEN 

IF op A .ClientPtr A .PhaseIVHostName * "" 
THEN « move Phase IV host name into buffer » 
END; 

IF op A .ClientPtr A .PhaseIVHostAddress * 0.0 
THEN « move Phase IV host address into buffer » 
END; 

IF op A .ClientPtr A .PhaseIVClientName * "" 
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THEN « move Phase IV client name into buffer » 
END; 

IF op A .ClientPtr A .PhaseIVClientAddress * 0.0 
THEN « move Phase IV client address into buffer » 
END; 

(* optionally: *) 

IF op A .ClientPtr A .PhaseIVHostName * "" 

OR op A .ClientPtr A .PhaseIVHostAddress * "" 
OR op A .ClientPtr A .PhaseIVClientName * "" 
OR op A .ClientPtr A .PhaseIVClientAddress * "" 
THEN « move V3 format host system time into buffer » 
END 
(* End option *) 
END; 

(* optionally: *) 

IF op A . Version = V4 

THEN « move V4 format host system time into buffer » 
END; 
(* End option *) 

buff A .Data[2 + «length of parameters*] := 0; (* end marker *) 

DLI.PutLong (buff, 3 + «length of parameters*, « transfer address from load file ») 
END; 

buff A Eength := 7 + «length of parameters* 
END DLLBuildParameterLoad; 

4.6 Upline dump algorithms 

This section defines the major algorithms used for upline dump. 

4.6.1 Upline dump client 

This section shows the Dump Client algorithm. 

In the case of a LAN upline dump, the server address is often already known; for example, it 
may be the load server used to load the client, or the "host" identified in the Parameter Load 
message from the load. If no dump server address is known, the first step is a Request Dump 
Service message to the Load Assistance multicast address. The first server that responds is 
used as the server for the rest of the dump. However, if the address of the dump server has 
already been chosen, then that server is used for the dump and the multicast to the Load Assis- 
tance address is skipped. For example, an implementation may elect always to dump to its 
"Supporting Host". 

Unlike downline load, it is usually not desirable to wait indefinitely for dump service. In- 
stead, the Request Dump Service is tried for some period of time; if no response is received, the 
dump is aborted and the system proceeds (typically with a restart). The algorithm below shows 
a DLL Transact for the Request Dump Service message (15 tries, 60 seconds total); other similar 
approaches are acceptable. If the dump client does want to wait indefinitely for a dump server, 
it should use the DLI.BackoffTransact procedure to transmit the Request Dump Service mes- 
sage. 

The algorithm shows a timeout of one minute on each transaction once the dump is under- 
way. The dump client does not have to do retransmissions at that stage, since the dump server 
does them, but it does need some sort of timeout to handle the case where the network is parti- 
tioned or the dump server has crashed. The dump server does 15 retries at 4 second intervals, 
so a one minute dump client timeout is recommended. 



62 



Operation 



The dump algorithm resembles the load algorithm in its general form, but there are some 
significant differences: 

• There are no sequence numbers; each Request Dump Data message specifies a start ad- 
dress, and the client responds with data from that address. 

• There is no acknowledgement to the Dump Complete message. 

PROCEDURE DLLDumpClient (circ: POINTER TO Circuit; server: LANAddress) 
RAISES {InsufficientResources, UnrecognizedCircuit, DataLinkError, Timeout} 

VAR op: POINTER TO Operation; 
buff: POINTER TO Buffer; 
msgtyp, memadr: INTEGER; 

BEGIN 

DLIAlloc (op, buff); (* Allocate necessary resources, if available *) 

op A .CircPtr := circ; 

op A .Op := DumpClient; 

op A . Version := Unknown; 

op A . Address := server; 

TRY 

IF op\CircPtr A .DataLink IN LANTypes AND server = NullAddress 
THEN (* LAN and server not selected yet *) 

DLLBuildReqDumpServ (op, buff); 

buff A .Destination := LoadAssistance; 

DLI Transact (op, buff, buff); 

op A Address := buff A .Source; (* Whoever answers is our server *) 
END; 

DLLBuildReqDumpServ (op, buff); (* Ask the selected server for dump service *) 
buff A .Destination := op A .Address; 
DLI Transact (op, buff, buff); 

(* Note: on entry to the loop we have just received the first Request Memory Dump message *) 
LOOP 

msgtyp = buff A .Data[0]; 

IF msgtyp = DumpComplete 

THEN EXIT (* Dump complete message — all finished *) 

END; 

memadr := DLI.GetLong (buff, 1); (* address to be dumped *) 

buff A .Data[0] := DumpData; (* Respond with Dump Data message *) 

DLI.PutLong (buff, 1 , memadr); (* Indicate base address of data *) 

« store data (if available) starting at byte 5 »; 

buf A .Length := 5 + « length of memory data »; 

DLI.ReqResp (op, buff, buff, OneMinute, op A .Version); 
END 
FINALLY 

DLI .Free (op, buff) 
END 

END DLLDumpClient; 

The procedures below show how the Dump protocol messages are constructed. Note that the 
Format Version byte (third byte) of the Request Dump Service message should be set to reflect 
what protocol version is being sent; the V3 requests have the value 1 in Format Version, and 
the V4 requests have the value 4. 

PROCEDURE DLLBuildReqDumpServ (op: POINTER TO Operation; buff: POINTER TO Buffer); 
BEGIN 

buff A .Data[0] := RequestDumpService; 

buff A .Data[l] := « Device Type code of data link being used »; 
buff A .Data[2] := « Format Version, see above »; 
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DLI.PutLong (buff, 3, « size of memory to be dumped »); 
buff\Data[7] := 2; 

(* Store TLV entry for Data Link Buffer Size *) 
DLLPutlnteger (buff, 8, 401); 
DLLPutlnteger (buff, 10, 2); 
DLLPutlnteger (buff, 12, op A .CircPtr A .SDUSize); 
buff A Length := 14 
END DLLBuildReqDumpServ; 

4.6.2 Upline dump server 

The following sections show the dump server algorithms. 

4.6.2.1 Upline dump server listener 

This section shows the operation of the dump server listener. It listens for dump service re- 
quests initiated by dump clients, and uses the Request Dump Service message and information 
in the Client database to decide whether and how to process the request. This process is active 
only if Dump service is enabled for the circuit. The outline of the algorithm is as follows: 

• First look for a client entry by circuit and (if a LAN) data link address. 

• If no match is found and this is a LAN, look for a client entry by circuit and device type. 

If no entry is found, this is an Unrecognized Client. If an entry is found, the file names 
it specifies are used as the dump files for this dump operation. 

• If this is a LAN and the original request was addressed to the Load Assistance 
multicast address, send an Assistance Volunteer message and wait for a directed Re- 
quest Dump Service message (indicating this node was selected). If none is received, 
quietly go back to listening for other requests. (This condition is not an error and no 
event should be logged in this case.) 

Note: as shown here the Assistance Volunteer is sent before any files are opened. An 
implementation may instead open files first, and not volunteer until it has sucessfully 
done the open. This will avoid volunteering when the client database points to inacces- 
sible files. 

• Dump the client according to the received request, with dump file and other parameters 
as determined above. 

After dump completion, the dump server simply goes back to waiting for more requests. The 
dump client will presumably attempt to restart, but this does not involve the dump server. In 
particular, the dump server should not send a Boot message or otherwise interfere with the re- 
start of the client. 

PROCEDURE DLLDumpServer (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

client: POINTER TO Client; 

buff: POINTER TO Buffer; 

device: DevType; 

count: INTEGER; 

i: INTEGER; 
EXCEPTION Quit; 
BEGIN 

NEW (op); (* Get an Operation record *) 

op A .CircPtr := circ; 
op A .Op := DumpServer; 
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LOOP 
TRY 

op A .Address := NullAddress; (* We'll listen to any remote station address *) 

op A . Version := Unknown; (* Accept any version *) 

DLI.Receive (op, buff, Infinite); (* Wait for a message, however long it takes *) 

IF buff A .Data[l] = 31 (* Special case *) 

THEN 

device := 37 (* 37 is LQA, 31 is alternate code for LQA *) 

ELSE 

device := buff A .Data[l] (* Get requester's device type *) 

END 

count := DLI.GetLong (buff, 3); (* Memory Size field *) 

IF « Data Link Buffer Size present in message » 

THEN op A .SDUSize := « Data Link Buffer Size from message » 

ELSE op A .SDUSize := 262 

END; 

op A .Client := DLI.FindClientByCircAddr (circ, buff A .Source); 
IF circ\DataLink IN LANTypes AND client = NIL 
THEN 

op A .Client := DLI.FindClientByCircDev (circ, device) 
END; 

IFop A .Client*NIL 
THEN 

op A .DumpFile := op A .Client A .DumpFile; 

op A . Dump Address := op A .Client A .DumpAddress; 

op A .DumpCount := count - op A .DumpAddress; 

(* make count = memory size - start address *) 
IF circ\DataLink IN LANTypes 

AND buff A .Destination[0] = 1 (* multicast request requires volunteer response *) 
THEN 

FOR i := 1 TO RetransmitMax 
DO 

LAN. Send Volunteer (op, buff); (* Volunteer to serve *) 

TRY 

DLI.Receive (op, buff, OneMinute); 
EXCEPT 

I Timeout: RAISE (Quit) 
END; 

« received Request Dump Service message should be the same as the multicast 
request that initiated the lookup. If not, quit and report a Dump Request Failed 
event, Reason = Protocol Error. » 

IF buff\Destination[0] = 

THEN EXIT (* Request Program direct to us, carry on *) 

ELSEIF i = RetransmitMax 

THEN RAISE (Quit) (* Volunteer isn't being heard, quit *) 

END 
END 
END; 

DLI.PerformDump (op,buff); (* Go perform the actual dump with these parameters *) 
« report a Dump Request Completed event » 
ELSE 

« report an Unrecognized Dump Client event » 
EXCEPT 

I Quit: (* Quit dump attempt quietly *) 

I ELSE « report a Dump Request Failed event, Reason as indicated by the exception » 

END; 

DLI.ReceiveDone (buff) 
END (* loop until told to stop *) 
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END DLLDumpServer; 

4.6.2.2 Upline dump data transfer phase 

This section shows the algorithm for the actual data transfer phase of the upline dump proc- 
ess. 

This procedure is given as input an Operation record, which specifies the address and MOP 
version of the client, as well as a dump file name or possibly sequence of file names and other 
dump parameters. This information was determined from a Request Dump Service message 
received from a dump client and from information in the Client database. 

The general flow of the dump is 

• Attempt to open dump file; try next in sequence if failure, until end of list or success. If 
failure, abort the dump. 

• Send Request Dump Data messages for each piece of the dump. As data is received, 
increment the dump address and decrement the count. Repeat until the dump count 
has been satisfied. 

• End the dump by sending the Dump Complete message once. 

The amount of data sent by the Dump Client in each Dump Data message can vary. The 
client may send as much data as will fit in the data link buffer size (as reported in the Request 
Dump Service) message. The client may also send less data. There is no requirement to send 
the same amount of data all the time. In particular, if a client needs to "delay" the dump server 
(for example because it has not finished gathering up all the data yet) it may respond to a re- 
quest with a Dump Data message containing no image data. In that case the server will simply 
repeat the request. There is no limit to the number of times the client may use this option. 

PROCEDURE DLLPerformDump (op: POINTER TO Operation; buff; POINTER TO Buffer) 

RAISES { DataLinkError, Timeout, FileOpenError } 
VAR memadr, count, segsiz, recadr, maxdatasize: INTEGER; 
BEGIN 

LOOP 

IF op A .DumpFile = { } 

THEN RAISE (FileOpenError) (* Ran out of files to try *) 

END; 

« select and remove a filespec from op A .DumpFile »; 
TRY 

« open the selected filespec »; 

EXIT (* Got the file we wanted *) 

EXCEPT 

ELSE (* keep going on any error *) 

END 
END; 

memadr := op A . Dump Address; 
count := op A .DumpCount; 
IF op A .Version = V3 

THEN (* Check and correct erroneous buffer size values *) 

IF op\SDTJSize > 1498 

THEN op\SDUSize := 1498 

ELSEIF op\SDUSize = 1030 

THEN op\SDUSize := 1010 

END 
END; 
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maxdatasize := MIN (op\SDUSize, op A .CircPtr A .SDUSize) - 5; 

(* Max image data in a Memory Dump Data message *) 

LOOP 

segsiz := MIN (maxdatasize, count); (* use what's left to dump if that's less than what fits *) 

DLI.BuildReqDump (op, buff, memadr, segsiz); 

LOOP 

DLI .Transact (op, buff, buff); 

recadr := DLI.GetLong (buff, 1); (* Get start of data returned by client *) 
IF recadr = memadr 

THEN EXIT (* that's what we asked for, handle it *) 

ELSE 

« quietly ignore this message » 
END 
END; 

segsiz := buff A .Length - 5; (* Length of received dump data *) 

« write received dump data, if any, to dump file »; 
memadr := memadr + segsiz; 
count := count - segsiz; 
IF count < 

THEN EXIT (* Nothing left to dump *) 

END 
END; 

(* Send the closing message of the dump *) 
buff A .Destination := op A .Address; 
buff A .Length := 1; 
buff\Data[0] := DumpComplete; 
DLI. Send (op, buff, op A .Version) 
END DLLPerformDump; 

PROCEDURE DLI .BuildReqDump (op: POINTER TO Operation, buff: POINTER TO Buffer; 

memadr, segsiz: INTEGER); 
BEGIN 

buff A .Destination := op A .Address; 
buff\Data[0] := ReqDumpData; 
DLI.PutLong (buff, 1, memadr); 
DLI.Putlnteger (buff, 5, segsiz); 
buff A .Length := 7 
END DLI .BuildReqDump; 

4.7 Loop algorithms for point to point data links 
4.7.1 Loop requester 

Unlike most other MOP functions, the loop requester is intentionally not tolerant of prob- 
lems on the link. Instead of retrying a number of times, it performs each request-response ex- 
change once. If it succeeds, the loop continues; if it fails, the loop is finished (and in error). 

PROCEDURE PTPUoopRequester (op: POINTER TO Operation; buff: POINTER TO Buffer) 

RAISES {InvalidResponse, DataLinkError, Timeout}; 
VAR i, j: INTEGER; 
BEGIN 

FOR i := 1 TO op\Count 

DO 

buff A .Data[0] := LoopData; (* Function code *) 
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DLI.Putlnteger (buff, 1 , i); (* Use sequence counter for receipt number. Note: any other 

receipt number that is different for each consecutive message 
may also be used. *) 

FOR j := to op A .Length - 1 
DO 

buff A .Data[j + 3] := op A .Data (* Load the test data pattern into the buffer *) 
END; 

buff A Length := op A Length + 3; (* Buffer length = loop data length + 3 byte header *) 

DLLReqResp (op, buff, buff, op A .CircPtr\RetransmitTimer, V4); 
IF buff A Length * op A .Length + 3 (* If wrong length response *) 
THEN 

RAISE (InvalidResponse, op A .Count - i) 
END; 

j := DLI.Getlnteger (buff, 1); (* Receipt number of response *) 

IF NOT (buff A .Data[0] IN { LoopData, LoopedData } ) 
ORj*i 

THEN (* If wrong function code or receipt number *) 

RAISE (InvalidResponse, op A .Count - i) 
END; 

FOR j := TO op A Length - 1 
DO 

IF buff A .Data[j + 3] * op\Data (* Check test data pattern *) 
THEN 

RAISE (InvalidResponse, op A .Count - i) 
END 
END 
END 

END PTPLoopRequester; 



4.7.2 Loop server 



There is always one Loop Server active for each point to point circuit. It keeps a receive 
pending at all times. When a message comes in (which will have function code LoopData), the 
message is modified appropriately and sent back to the sender. 

Note that the Loop Server is required to support the full range of valid message sizes for 
each data link. 



PROCEDURE PTPLoopServer (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 
BEGIN 

NEW (op); 

op A .CircPtr := circ; 

op A .Op := LoopServer; 

LOOP 

DLI .Receive (op, buff, Infinite); 
buff\Data[0] := LoopedData; 
DLI.Send (op, buff, V4); 
DLLReceiveDone (buff) 
END 

END PTPLoopServer; 



(* Get an Operation record *) 



(* Wait for a message, however long it takes *) 
(* Change the message code *) 
(* Send it back (version is not applicable, actually) *) 
(* Done using the receive buffer *) 
(* Repeat that forever *) 
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4.8 Loop algorithms for LAN data links 
4.8.1 Loop requester 

The procedures below define the algorithm for the Loop Requester. 

The LAN loopback protocol uses two message codes, "Forward Data" and "Reply". Forward 
Data specifies that the message is to be sent onwards to another station. Reply indicates that 
the message terminates at this station and should be delivered to a Loop Requester. The mes- 
sage sent by the requester in effect consists of a Reply, enveloped in a number of Forward Data 
envelopes. This provides the mechanism needed to do "loop assistance". 

If assisted loopback is desired, the caller will often supply the data link address of the sta- 
tion to use as assistant. If no assistant address is supplied, then the Loop Requester attempts 
to find an assistant. Stations willing to be assistant listen to the Loopback Assistance multicast 
address. To find an assistant, the requester sends a loop message to that multicast address, 
and uses the source address from the first received response as the assistant address for the 
remainder of the operation. 

Note that all Loop messages (except for the one used to find a loop assistant) are sent as sin- 
gle attempts. Since the purpose of the Loop directive is to look for network problems, no retries 
are done during the operation. Otherwise soft errors would be obscured. 

PROCEDURE LANLoopRequester (op: POINTER TO Operation; buff: POINTER TO Buffer) 

RAISES {InvalidResponse, DataLinkError, Timeout}; 
VAR i, j , offset, buflen: INTEGER; 

addresses: SET OF LANAddress; 

target: LANAddress; 
BEGIN 

op A . Version := V4; (* Initially use V4 format *) 

addresses := op A . Addresses; 
FOR i := 1 TO op\Count 
DO 

IF i = 1 

THEN (* For first one we have to select the address *) 

LAN.FindAssistant (op, buff); (* Select assistant if we need one *) 

LOOP 

IF addresses = { } 

THEN (* No target addresses left to try *) 

IF op A .Version = V4 

THEN (* V4 didn't work, try it with V3 *) 

op A . Version := V3; 
addresses := op A Addresses; 

LAN.FindAssistant (op, buff);(* Find a V3 assistant if we need one *) 
ELSE RAISE (Timeout) (* Both versions received no response *) 
END 
ELSE 

target := « select and remove an address from addresses »; 

LAN.BuildLoopMsg (buff, target, op A .AssistanceType, op A .AssistantAddress, op, i, 
buflen); 

TRY 

DLI.RequestResponse (op, buff, buff, op A . Version); 

op A Address := target; (*If we get an answer, that's the address to use *) 

EXIT (* Leave the address search loop *) 

EXCEPT 

I Timeout: (* If no answer, keep on trying addresses *) 

END 
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END 

END (* end of target address search loop *) 

ELSE (* Not first message *) 

LAN.BuildLoopMsg (buff, target, op A .AssistanceType, op A .AssistantAddress, op, i, buflen); 

DLLReqResp (op, buff, buff, op A . Version) 
END; 

IF buff A .Length * buflen (* If wrong length response *) 

THEN 

RAISE (InvalidResponse, op A .Count - i) 
END; 

offset := DLI.Getlnteger (buff, 0); (* Get skip count *) 

j := DLI.Getlnteger (buff, offset + 2); (* Receipt number of response *) 

IF j * i (* If wrong receipt number *) 

OR offset + 4 + op A .Length * buflen (* or wrong offset *) 

THEN 

RAISE (InvalidResponse, op A .Count - i) 
END; 

FOR j := to op A Length - 1 
DO 

IF buff A .Data[j + offset + 4] * op A .Data (* Check test data *) 
THEN 

RAISE (InvalidResponse, op A .Count - i) 
END 
END 
END 

END LAN.LoopRequester; 

The following procedure builds a LAN Loopback message. The message consists of a Reply 
message (containing the data), preceded by one or more Forward headers. These headers list 
the addresses on the path the message is to take. For example, if Transmit assistance is being 
used, the Loopback message destination address is the assistant address; the first Forward 
header contains the target station address, and the second forward header contains the station 
address for our circuit. 

PROCEDURE LAN .BuildLoopMsg (buff: POINTER TO Buffer; target: LANAddress; help: HelpType; 

assistant: LANAddress; op: POINTER TO Operation; receipt: INTEGER; VAR buflen: INTEGER); 
VAR offset: INTEGER; 
BEGIN 

DLLPutlnteger (buff, 0, 0); (* Initial skip count = *) 

IF help IN {Transmit, Full} (* If first hop is to assistant *) 

THEN 

buff A .Destination := assistant; (* Set first hop destination address *) 

LAN .Forward (buff, 2, target); (* First Forward header points to target *) 

offset := 10 

ELSE (* Receive assistance or no assistance, first hop to target *) 

buff A .Destination := target; 

offset := 2 
END; 

IF help IN {Receive, Full} (* If assistant used on the way back *) 

THEN 

LAN .Forward (buff, offset, assistant); 
offset := offset + 8 
END; 

LAN .Forward (buff, offset, op A .CircPtr A .DataLinkAddress); 

(* Last forward header points back to us *) 

offset := offset + 8; 

DLLPutlnteger (buff, offset, Reply); (* Put in Reply header *) 

DLLPutlnteger (buff, offset + 2, receipt); 
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FOR j := to op A .Length - 1 
DO 

buff A .Data[j + offset + 4] := op A .Data (* Load the test data pattern into the buffer *) 
END; 

buflen := op A .Length + offset + 4; (* total loop message length *) 

buff A .Length := buflen 
END LAN .BuildLoopMsg ; 

PROCEDURE LAN.Forward (buff: POINTER TO Buffer; offset: INTEGER; address; LANAddress); 
BEGIN 

DLI.Putlnteger (buff, offset, ForwardData); 
DLLPutAddress (buff, offset + 2, address) 
END LAN .Forward; 

PROCEDURE LAN .Find Assistant (op: POINTER TO Operation; buff: POINTER TO Buffer); 

VAR assistants: SET OF LANAddress; 

BEGIN 

IF op A .AssistanceType * None (* Need to select an assistant? *) 

THEN 

assistants := op A .AssistantAddresses; (* Initialize the list of addresses to try *) 
LOOP 

IF assistants = { } 

THEN (* No assistant addresses left to try *) 

IF op A . Version = V4 

THEN (* V4 didn't work, try it with V3 

op A . Version := V3; 

assistants := op A .AssistantAddresses 
ELSE RAISE (Timeout) (* Both versions received no response *) 
END 
ELSE 

target := « select and remove an address from assistants »; 
LAN .BuildLoopMsg (buff, target, None, NullAddress, op, -1); 
TRY 

DLITransact (op, buff, buff); (* Do a "direct" loop to the selected address *) 
op A .AssistantAddress := buff A .Source; (* Whoever responds is the assistant *) 
EXIT (* Leave the assistant search loop *) 

EXCEPT 

I Timeout: (* If no answer, keep on trying addresses *) 

END 
END 
END 
END 

END LAN.FindAssistant; 

4.8.2 Loop server 

There is always one Loop Server active for each LAN circuit. It keeps a receive pending at 
all times. When a message comes in (which will have function code ForwardData), the message 
is modified appropriately and sent onwards. Invalid messages are quietly ignored. 

Note that the Loop Server is required to support the full range of valid message sizes for 
each data link. 

PROCEDURE LANUoopServer (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

offset: INTEGER; 
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(* Get an Operation record *) 



We'll listen to any remote station address *) 
Accept any version *) 

Wait for a message, however long it takes *) 
Get the offset value from message *) 
Must have our header plus next guy's msgtype *) 



nexthop: LANAddress; 
BEGIN 

NEW (op); 
op A .CircPtr := circ; 
op A .Op := LoopServer; 
LOOP 

op A Address := NullAddress; 
op A .Version := Unknown; 
DLI .Receive (op, buff, Infinite); 
offset := DLI.Getlnteger (buff, 0); 
IF buff A .Length > offset+10 
THEN 

nexthop := GetAddress (buff, offset+2); (* Get address to send to *) 
IF nexthop[0] =0 (* Must not be a multicast address *) 

THEN 

buff A .Destination := nexthop; (* Forwarding address is our destination *) 
DLI.Putlnteger (buff, 0, offset+8); (* Update Offset in message buffer *) 
DLI. Send (op, buff, op A .Version) 
END 
END; 

DLLReceiveDone (buff) (* Done using the receive buffer *) 

END (* Repeat that forever *) 

END LAN LoopServer; 



4.9 XID and TEST algorithms 

This section describes the operation of the Test and Query Requesters. These are function- 
ally quite separate from the remainder of MOP, for example because they do not use the normal 
LLC data transfer services of the data link. Note that the corresponding server (responder) al- 
gorithms are not shown here; they are defined in the IEEE 802.2 (LLC) standard. 

4.9.1 Test requester 

PROCEDURE LANTestRequester (op: POINTER TO Operation) 

RAISES {InvalidResponse, DataLinkError, Timeout}; 
VARi,j: INTEGER; 

buff: POINTER TO Buffer; 

target: LANAddress; 

ssap: SAP Address; 
BEGIN 

ssap := LAN.SelectaSAP (op); (* Pick a source SAP to use *) 

LAN. EnableS AP (op A .CircPtr\LLCport, ssap); (* Enable that SAP for the duration *) 

buff := op A .buff; 

TRY 

FOR i := 1 TO op A .Count 
DO 

buff A .Data[0] := op A .SAP; (* Destination SAP address *) 

buff A .Data[l] := ssap; (* Source SAP address = system specific, Command *) 

buff\Data[2] := LLCTEST; (* Frame Control = TEST, P/F = *) 

DLLPutlnteger (buff, 3, i); (* Use sequence counter for receipt number. Note: any other 

receipt number that is different for each consecutive message 
may also be used. *) 

FOR j := to op A Length - 1 
DO 

buff A .Data[j + 5] := op A .Data (* Load the test data pattern into the buffer *) 
END; 
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buff A .Length := op A .Length + 5; (* Buffer length = loop data length + 5 byte header *) 
IF i = 1 (* Have to select an address *) 

THEN 
LOOP 

IF op A . Addresses = { } 

THEN RAISE (Timeout) (* No response from anything *) 

END; 

target := « select and remove an address from op A Addresses »; 

buff A .Destination := target; 

TRY 

LAN LLCReqResp (op, buff, LLCTEST); 

(* Do a request/response, looking for TEST response *) 
op A Address := target; (* If it works, that's the target address *) 

EXIT 
EXCEPT 

I Timeout: (* If no answer, keep on trying addresses *) 

END 

END (* End of target address search loop *) 

ELSE (* Not first message *) 

LAN LLCReqResp (op, buff, LLCTEST); 

(* Do a request/response, looking for TEST response *) 

END; 

IF buff A Length * op A Length (* If wrong length response *) 

OR buff\Data[l] * op A .SAP + 01H (* Must be a response frame from the right SAP *) 
THEN 

RAISE (InvalidResponse, op A .Count - i) 
END; 

j := DLI.Getlnteger (buff, 3); (* Receipt number of response *) 
IF j * i (* If wrong receipt number *) 

THEN 

RAISE (InvalidResponse, op A .Count - i) 
END; 

FOR j := to op A Length - 1 
DO 

IF buff A .Data[j + 5] * op\Data (* Check test data *) 
THEN 

RAISE (InvalidResponse, op A .Count - i) 
END 
END 
END 
FINALLY 

LAN.DisableSAP (op A .CircPtr A .LLCport, ssap) (* Done with the SAP) *) 

END 

END LANTestRequester; 

4.9.2 Query requester 

PROCEDURE LAN .Query Requester (op: POINTER TO Operation; 

VAR LLCTypes: BITSET; VAR Window: INTEGER) 

RAISES {InvalidResponse, DataLinkError, Timeout}; 
VAR buff: POINTER TO Buffer; 

target: LANAddress; 

ssap: SAPAddress; 
BEGIN 

ssap := LAN.SelectaSAP (op); (* Pick a source SAP to use *) 

LAN. EnableS AP (op A .CircPtr A .LLCport, ssap); (* Enable that SAP for the duration *) 

buff := op A .buff; 
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buff A .Length := 6; 
buff A .Data[0] := op\SAP; 
buff A .Data[l] := ssap; 
buff A .Data[2] :=LLCXID; 
buff A .Data[3] :=81H; 
buff A .Data[4] :=01H 
buff A .Data[5] :=00H 
TRY 

LOOP 

IF op A .Addresses = { } 

THEN RAISE (Timeout) 

END; 

target := « select and remove an address from op A Addresses »; 

buff A .Destination := target; 

TRY 

LAN.LLCTransact (op, buff, LLCXID); 

(* Do a request/response, looking for XID response *) 
(* If it works, that's the target address *) 



(* 3 bytes LLC header, 3 bytes info *) 
(* Destination SAP address *) 

(* Source SAP address = system specific, Command. *) 
(* Frame Control = XID, P/F = *) 
(* IEEE basic format XID *) 
(* We say we do LLC class 1 only *) 
(* No window size *) 



(* No response from anything *) 



op A Address := target; 

EXIT 
EXCEPT 
I Timeout: 
END 
END; 

IF buff A .Length * 6 
THEN 

RAISE (InvalidResponse) 
END; 

IF buff\Data[l] * op A .SAP + 01H 

OR buff\Data[3] * 81H 
THEN 

RAISE (InvalidResponse) 
END; 

LLCTypes := buff\Data[4] MOD 20H; (* Get bitmask for supported LLC types *) 

Window := buff A .Data[5] DIV 2 (* ... and window size *) 

FINALLY 

LAN. Disables AP (op A .CircPtr A .LLCport, ssap) (* Done with the SAP) *) 

END 

END LAN.QueryRequester; 



(* If no answer, keep on trying addresses *) 



(* If wrong length response *) 



(* Must be a response frame from the right SAP *) 
(* ... and format = IEEE Basic Format *) 



4.10 Console server algorithms 

There is always one Console Server active for each LAN circuit. It keeps a receive pending 
at all times. The messages it can receive are Request ID, Request Counters, and, if supported 
and enabled, Boot and Console Carrier messages. It checks the message type, and dispatches 
appropriate to build the response. 

PROCEDURE LAN.ConsoleServer (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

function: Byte; 

timeout: Time; 
BEGIN 

NEW (op); (* Get an Operation record *) 

op A .CircPtr := circ; 
op A .Op := ConsoleServer; 
LOOP 

op A Address := NullAddress; (* We accept requests from any source *) 
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op A . Version := Unknown; (* Accept any version *) 

IF circ A .ConsoleUser = NullAddress 

THEN (* Console not currently reserved *) 

DLI.Receive (op, buff, Infinite) (* Wait for a message, however long it takes *) 
ELSE 

timeout := « time remaining before circ A .ReservationTimer expires »; 
TRY 

DLI.Receive (op, buff, timeout); (* Wait for a message, up to reservation timeout *) 

EXCEPT 
I Timeout: 

circ A .ConsoleUser := NullAddress; (* Cancel reservation *) 

DLI.Receive (op, buff, Infinite) (* Wait for a message, however long it takes *) 

END 
END; 

function := buff A .Data[0]; (* Get the function code from the buffer *) 

IF function = RequestID (* Do the right thing given the function code *) 

THEN LAN. SysIDResponse (op, buff) 
ELSEIF function = RequestCounters 
THEN LAN.CountersResponse (op, buff) 

ELSEIF function IN { ReserveConsole, ReleaseConsole, ConsoleCommand } 

THEN LAN.ConsoleCarrierResponse (op, buff) 

END 

ELSEIF function = Boot AND « Boot supported » 
THEN DLLReceiveBoot (op, buff); 

DLI.ReceiveDone (buff) (* Done using this receive buffer *) 

END 

END LAN.ConsoleServer; 



4.10.1 Periodic System ID transmission 



For each LAN circuit, there is one Periodic System ID transmitter process. Strictly speak- 
ing, this is part of the Console Server, but it is simpler to show it as a separate process. It has a 
very simple task: every 5 minutes ± 20% it sends a System ID message. The first is sent in V4 
format, the next in V3 format, and so on alternating the format. 

PROCEDURE LAN.PeriodicSysID (circ: POINTER TO Circuit); 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

tmo: Time; 
BEGIN 

NEW (op); (* Get an Operation record *) 

op A .CircPtr := circ; (* Initialize what we need *) 

NEW (buff) ; (* Allocate a buffer *) 

buff A .Destination := ConsoleMulticast; (* Send periodic messages to this address *) 

LOOP 

op A .Version := V4; (* First we send a V4 format System ID *) 

LAN.SendSysID (op, buff, 0); (* Send a System ID with receipt number of zero *) 
tmo := FiveMinutes * (0.8 + 0.4 * Random ( ) ); (* Compute the delay time *) 

System.Wait (tmo); (* ... and wait for that long *) 

op A Version := V3; (* Next we send a V3 format System ID *) 

LAN.SendSysID (op, buff, 0); (* Send a System ID with receipt number of zero *) 
tmo := FiveMinutes * (0.8 + 0.4 * Random ( ) ); (* Compute the delay time *) 

System.Wait (tmo) (* ... and wait for that long *) 

END (* Repeat all this indefinitely *) 
END LANPeriodicSysID; 



4. 1 0.2: Build a System ID message 
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4.10.2 Build a System ID message 



This procedure builds a System ID message and sends it. Depending on the version number 
of the intended recipient (given by the Version field of the Operation record that is passed), cer- 
tain fields are included or omitted; refer to the description of the System ID message in Sections 
5.5.3 and G.6. The receipt number to be used is passed as an argument. For periodic System 
ID transmissions, the value is zero; for responses to requests, the value is what was sent in the 
Request ID message. 

PROCEDURE LAN.SendSysID (op: POINTER TO Operation; buff: POINTER TO Buffer; 

receipt: INTEGER); 
BEGIN 

buff A .Data[0] := SysID; (* Function code *) 

buff\Data[l] := 0; (* Reserved byte *) 

DLI.Putlnteger (buff, 2, receipt); (* Put in the 16-bit receipt number *) 

« now put in the other fields. »; 
DLI.Send (op, buff, op A . Version) 
END LAN.SendSysID; 



4.10.3 Response to Request ID 



PROCEDURE LAN .Sy sIDResponse (op: POINTER TO Operation; buff: POINTER TO Buffer); 

VAR receipt: INTEGER; 

BEGIN 

IFbuff A .Length>4 

THEN 

receipt := DLI.Getlnteger (buff, 2); 
buff A Destination := buff A .Source; 
LAN.SendSysID (op, buff, receipt) 
END 

END LAN .Sy sIDResponse; 



(* Make sure request is long enough to be valid *) 

(* Get receipt number *) 

(* Response goes to sender of request *) 

(* Now construct the response and send it *) 



4.10.4 Response to Request Counters 



The specifics of the counters response depend somewhat on which datalink is being used, but 
the whole algorithm is shown here anyway for simplicity. In particular, the CSMA/CD counters 
are sent with a different response message than for other datalinks, and only the CSMA/CD 
counters response can be sent to a V3 MOP implementation. 

PROCEDURE LAN.CountersResponse (op: POINTER TO Operation; buff: POINTER TO Buffer); 
VAR counterblock: ARRAY OF Counter; 

receipt: INTEGER; 
BEGIN 

IF buff A Length a 3 (* Make sure request is long enough to be valid *) 

THEN 

receipt := DLI.Getlnteger (buff, 1); (* Fetch receipt number from request *) 
buff A Destination := buff A .Source; (* Response goes to sender of request *) 
IF op A .CircPtr\DataLink = CSMACD 
THEN 

buff A Data[0] := CSMACDCounters; (* Response message code *) 
DLI.Putlnteger (buff, 1 , receipt); (* Store receipt number in response *) 
counterblock := CSMACD Get (op\CircPtr.LinkName, "COUNTERS"); 
IF op A . Version = V4 
THEN 

« move counters into buffer starting at byte 3 »; 

buff A .Length := 203 (* Length of V4 format CSMA/CD counters *) 



76 



Operation 



ELSE 

« convert counters to V3 form »; 

« move converted counters into buffer starting at byte 3 »; 
buff A .Length := 57 (* Length of V3 format CSMA/CD counters *) 

END; 

DLI.Send (op, buff, op A . Version) 
ELSEIF op A .CircPtr A .DataLink = FDDI (* Only other alternative currently is FDDI *) 

THEN 

IF op A .Version = V4 

THEN 

buff A .Data[0] := OtherCounters; (* Response message code *) 

DLLPutlnteger (buff, 1 , 5); (* Store data link code (5 = FDDI) *) 
DLI.Putlnteger (buff, 3, receipt); (* Store receipt number *) 
counterblock := FDDI .Get (op A .CircPtr.LinkName, "COUNTERS"); 
« move counters into buffer starting at byte 4 »; 

buff A Length := 260; (* Length of counter message for FDDI counters *) 

DLI.Send (op, buff, op A Version) 
END (* If V3 requester, ignore the request *) 

END 
END 

END LAN.CountersResponse; 

4.10.5 Console carrier server 

This section shows the algorithms for the Console Carrier portion of the Console Server. 

For Console Command messages, there is a one-bit sequence number to deal with lost mes- 
sages. If a retransmitted Console Command message is received, the previously sent response 
is resent. Note that this is the same message as before, even if additional console response data 
is available at this time. New console response data is considered only when a new Console 
Command message is received. 

The circuit reservation timer ensures that the console is released if no console carrier mes- 
sage is received from the console carrier requester for the timeout period. The timeout should 
be long enough to allow for message loss and recovery by retransmission, but not so long that 
the console remains unavailable for an extensive period of time. The recommended value for 
the reservation timeout is 60 seconds. (This corresponds to the 15 retries done by the requester 
at the default 4 second retransmit interval, so the client and server would give up at about the 
same time if communication is lost.) 

The purpose of the console carrier is to provide the common ASCII local console function via 
a simple low level network protocol. Character stream data is sent by the console carrier re- 
quester and any console output is returned in a character stream by the console carrier server. 
The server should echo input (characters received from the requester) in the same manner as it 
would echo local console data. 

PROCEDURE LAN.ConsoleCarrierResponse (op: POINTER TO Operation; buff: POINTER TO Buffer); 

VAR function, cflags, seq: INTEGER; 

BEGIN 

IF NOT ( ConsoleCarrier IN op A .CircPtr A .Functions) 

THEN RETURN (* Ignore message if not enabled or not supported *) 

END; 

function := buff A .Data[0]; (* Get the function code from the buffer *) 

IF function = ReserveConsole 

THEN 

IF op A .CircPtr A .ConsoleUser = NullAddress 

AND « verification field in message is valid » 
THEN 
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op A .CircPtr A .ConsoleUser := buff A .Source; 

StartTimer (op A .CircPtr A .ReservationTimer, « reservation timeout » ); 
op A .CircPtr A .ConsoleSeq := 1 (* Next expected sequence number *) 
END 

ELSEIF function = ReleaseConsole 
THEN 

IF buff A .Source = op A .CircPtr A .ConsoleUser 
THEN 

op A .CircPtr A .ConsoleUser := NullAddress; 
StopTimer (op A .CircPtr A .ReservationTimer) 
END 

ELSE (* It's a Console Command message *) 

IF buff A . Source = op A .CircPtr A .ConsoleUser 
THEN 

cflags := buff A .Data[l]; (* Get command flags *) 

seq := cflags MOD 2; (* Sequence number *) 

IF seq = op A . CircPtr A .ConsoleSeq (* New message *) 

THEN 

StartTimer (op A .CircPtr A .ReservationTimer, « reservation timeout » ); 
IF (cflag DIV 2) MOD 2=1 (* Check Command Break flag *) 
THEN « issue Break to console » 
END; 

« issue command data (if any) to console »; 
op A .CircPtr A .ConsoleSeq := seq; 

cflag := seq; (* Sequence number goes into response message *) 

IF « any command data was lost » 
THEN cflag := cflag + 2 
END; 

IF « any response data was lost since last new Console Command message » 

THEN cflag := cflag + 4 

END; 

buff A .Data[0] := ConsoleResponse; 
buff\Data[l] := cflag; 

« load response data, if any, into buff A .Data starting at byte 2 »; 

buff A .Length := 2 + « length of response data » 
ELSE buff A .Data := « previously sent response » 
END; 

buff A .Destination := buff A .Source; (* Response goes to sender of request *) 
DLI.Send (op, buff, op A .Version) (* Send the response message *) 
END 
END 

END LAN.ConsoleCarrierResponse; 

4.10.6 Received Boot message processing 

The purpose of the Boot message is to terminate whatever the node is doing and force it to 
reboot. The Boot message can contain parameters which change the normal reboot actions. 

In order to be most effective, recognition of the Boot message should not depend on the cor- 
rect operation of system software. This means that recognition of the Boot message should be 
done in the data link hardware or in the data link adapter firmware, if possible. When this is 
not possible, recognition of the Boot message at a low level in the system software (e.g., in the 
device driver at interrupt level) may still provide a useful function. 

Since the Boot message aborts normal operation of the node, it is essential that there is a 
way to disable recognition of the Boot message. For systems that are usually managed locally, 
disabling Boot recognition by default is generally appropriate. In addition, all implementations 
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must check the Verification field of the Boot message and ignore any message that does not 
have the correct value in the Verification field. The expected Verification value must be setta- 
ble. Note that settable verification alone is no substitute for being able to disable Boot message 
recognition entirely. 

Once a Boot message has been validated, the system should be rebooted. If possible, the im- 
plementation should preserve the information in the Boot message and pass that to the reboot 
process. This gives the sending node control over how the target node will restart. In particu- 
lar, support for the Control field value 1 ("Boot Server — Requesting System") is important for 
the Load directive to work reliably. However, implementations that preserve no state and sim- 
ply execute the default boot actions are permitted. 

If the Control field is 1 ("Boot Server - Requesting System") the system should execute the 
Load Requester to reload the Secondary and/or Tertiary Loader (if required), the Operating 
System, and the CMIP Script or Management File (if required). Each of these loads should go 
directly to the node sending the Boot message, bypassing the multicast to the Load Assistance 
address. 

If the System Software ID field is present in the Boot message, its value should be used in 
the Software ID field of the Request Program message when requesting the Operating System 
load. Similarly, if the Script Software ID field is present in the Boot message, its value should 
be used in the Software ID field of the Request Program message when requesting the CMIP 
Script load. For other load steps, or when those Software ID fields are omitted from the Boot 
message, the system should supply its default value in the Software ID field of the Request Pro- 
gram message. 

4.10.7 Configuration monitor 

The Configuration Monitor is started (for a particular circuit) by the Enable Circuit directive 
and stopped by the Disable directive. It receives all System ID messages addressed to the Con- 
sole Multicast address. There can be multiple Configuration Monitors, one for each LAN circuit; 
these operate independently. 

Received System ID messages are identified by their data link source address. If a Station 
subentity exists for that address, the information in that subentity is updated. If not, then a 
new Station subentity is created (resources permitting) and loaded with information from the 
System ID message. 

In either case, the attributes of the Station subentity (see Table 14) are loaded, with appro- 
priate data type conversions as needed, from the corresponding fields of the System ID mes- 
sage. Note that the Node ID attribute is encoded in the System ID message in two parts, which 
are concatenated to form the attribute. Any fields for which there is no corresponding attribute 
are ignored. The Last Report attribute is updated to reflect the time when the System ID mes- 
sage was received. 

When the Configuration Monitor is stopped for a circuit, all Station subentities of that cir- 
cuit are deleted. 

4.10.8 Console carrier requester 

The console carrier requester algorithm is shown below. 

The central part of the algorithm is a polling loop in which the target station is polled peri- 
odically for new console carrier data. New console input is also sent to the target in this loop as 
needed. 



4. 1 0. 8: Console carrier requester 
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Note: 

The polling should be done frequently enough to carry console data from the tar- 
get to the requester promptly and avoid console response data loss, but not so 
often that the target station is overloaded by the polling activity. The minimum 
permitted poll interval is 80 milliseconds. Somewhat longer poll intervals are 
generally more appropriate (several hundred milliseconds). Adaptive algo- 
rithms may be used for increased efficiency; for example, poll at 100 ms inter- 
vals until no new data is seen for some time (e.g., 10 seconds); then poll at 1 s 
intervals; switch back to 100 ms intervals when new data is seen in either direc- 
tion. 

The timeout for each poll should be substantially longer than the poll rate (the default time- 
out of 4 seconds is appropriate) to ensure that the timeout is longer than the likely packet life- 
time in the network. This is necessary because the protocol only has a one bit sequence num- 
ber. 

The purpose of the console carrier is to provide the common ASCII local console function via 
a simple low level network protocol. Character stream data is sent by the console carrier re- 
quester and any console output is returned in a character stream by the console carrier server. 
The requester should assume that the server will echo input (characters received from the re- 
quester) in the same manner as local console data; therefore the requester should not echo char- 
acters locally. 

PROCEDURE LAN.CarrierRequester (circ: POINTER TO Circuit) 

RAISES {InvalidResponse, DataLinkError, Unavailable, Timeout}; 
VAR op: POINTER TO Operation; 

buff: POINTER TO Buffer; 

seq, cflags, rseq: INTEGER; 

target: LANAddress; 
BEGIN 

DLIAlloc (op, buff); (* Allocate necessary resources, if available *) 

TRY 

op A .Op := ConsoleCarrier; 

op A .CircPtr := circ; 

op A Address := NullAddress; 

op A .Version := Unknown; 

LOOP 

IF op A . Addresses = { } 

THEN RAISE (Timeout) (* No response from anything *) 

END; 

target := « select and remove an address from op A Addresses »; 

LAN .BuildReqID (buff, target); 

TRY 

DLI Transact (op, buff, buff); 

op A .Address := target; (* If it works, that's the target address *) 

EXIT 
EXCEPT 

I Timeout: (* If no answer, keep on trying addresses *) 

END 
END; 

IF « console carrier not supported » 
THEN RAISE (Unavailable) 
END; 

FOR i := 1 TO RetransmitMax 
DO 

LAN.BuildReserve (buff, op A Address); (* Try to reserve console *) 
DLI.Send (op, buff, op A .Version); 
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System.Wait ( « a few milliseconds » ); 

(* Wait to allow target to make the reservation and update the 
System ID it sends to reflect the reservation *) 

LAN .BuildReqID (buff, op A .Address); (* Check the result *) 

DLI .Transact (op, buff, buff); 

IF « console reserved by circ A .DataLinkAddress » 

THEN EXIT 

ELSEIF « console reserved » 

THEN RAISE (Unavailable) (* Someone else got it first *) 
END; 

IF i = RetransmitMax 
THEN RAISE (Timeout) 
END 
END; 

seq := 1 ; (* Initial sequence number *) 

LOOP 

IF « user is finished with console carrier » 

THEN EXIT (* Leave the polling loop *) 

System.Wait (« poll delay »); (* See note above *) 

LAN.BuildConsolePoll (buff, op A .Address, seq); 

DLI Transact (op, buff, buff); 

cflags := buff A .Data[l]; (* Control flags from console response message *) 

rseq := cflags MOD 2; (* Received sequence number *) 

IF rseq = seq 

THEN (* Valid response to our poll *) 

seq := (seq + 1) MOD 2; (* Update the transmit sequence number *) 
« send console response data to user »; 

(* This queues the data, it doesn't wait for it to be handled. If 
there is no room for more, discard the data *) 

IF (cflags DIV 2) MOD 2 = 1 

THEN (* Data lost flag(s) set *) 

« send data lost error indication(s) to user » 
END; 

« get new console command data from user » 
END 
END; 

FOR i := 1 TO RetransmitMax 
DO 

buff A Length := 1; 

buff A .Destination := op A Address; 

buff A .Data[0] := ReleaseConsole; 

DLI .Send (op, buff, op A . Version) (* Release the console *) 

System.Wait ( « a few milliseconds » ); 

(* Wait to allow target to release the reservation and update 
the System ID it sends to reflect the release *) 

LAN .BuildReqID (buff, op A Address); (* Check the result *) 

DLI Transact (op, buff, buff); 

IF NOT « console reserved by circ A .DataLinkAddress » 

THEN EXIT (* Leave loop if not reserved, or reserved by another *) 

END 
END 
FINALLY 

DLI .Free (op, buff) 
END 

END LAN.CarrierRequester; 



LAN .BuildReqID (buff: POINTER TO Buffer; target: LANAddress); 
buff A Length := 4; 



4.11: MOP protocol primitives 
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buff A .Destination := target; 
buff\Data[0] := RequestID; 

buff\Data[l] := 0; (* reserved field *) 

DLI.Putlnteger (buff, 2, « a suitable non-zero receipt number ») 
END LAN .B uildReqID ; 

LAN.BuildReserve (buff: POINTER TO Buffer; target: LANAddress); 

buff A .Length := 9; 

buff A .Destination := target; 

buff A .Data[0] := ReserveConsole; 

« load verification value into bytes 1-8 » 
END LAN.BuildRereserve; 

LAN.BuildConsolePoll (buff: POINTER TO Buffer; target: LANAddress, seq: INTEGER); 
buff A .Destination := target; 
buff A .Data[0] := ConsoleCommand; 
IF « break requested by user » 
THEN buff A .Data[l] := seq+2 
ELSE buff A .Data[l] := seq 
END; 

« load user console command data, if any, into bytes 2 and up »; 
buff A Length := 2 + « length of command data » 
END LAN.BuildConsolePoll; 



4.11 MOP protocol primitives 

The algorithms presented in this section perform the basic protocol message exchanges: 
transmit, request/response with or without retry. 

4.11.1 Send message 



This procedure is the common interface to the data link dependent transmit function. It 
transmits a single message. It returns when the data link is finished with the buffer (which 
may or may not imply successful transmission of the message). 

PROCEDURE DLI.Send (op: POINTER TO Operation; msg: POINTER TO Buffer, ver: MOPVersion) 

RAISES {DLD.CommonExceptions}; 
BEGIN 

DLD Transmit (op, msg, ver) ; 
LOOP 
TRY 

DLDTransmitPoll (op, msg); 
RETURN 
EXCEPT 
I NotComplete: 
END 
END 
END DLI.Send; 



(* Issue the Transmit request *) 



(* Check if transmit has finished *) 
(*Ithas... *) 

(* Keep going if not done yet *) 



4.11.2 Receive message with timeout 

This procedure is the common interface for receiving a message. It attempts to obtain a mes- 
sage from the receive dispatcher. If a message is received within the specified timeout period, 
that message is returned. Otherwise, an exception is generated when the timeout period has 
expired. 
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This procedure is used by a thread which is processing a particular MOP operation. In the 
model used here, the receive dispatcher dispatches received packets, based on data link enve- 
lope, protocol ID, remote data link address (for LANs), and MOP message code, to the appropri- 
ate operation thread. As a result, this procedure returns only "appropriate" messages. Refer to 
the receive dispatcher algorithms (Section 4.12) for more detail. 

Note that receipt of a message establishes the remote station address and MOP version 
number to be used for the current operation. 

PROCEDURE DLLReceive (op: POINTER TO Operation; VAR msg: POINTER TO Buffer; 

tmo: Time; ver: MOPVersion) 

RAISES {Timeout}; 
BEGIN 

StartTimer (op A Timeout, tmo); (* Start the receive timeout *) 

LOOP 

IF Expired (op A Timeout) (* Check for timer expiry *) 

THEN 

RAISE (Timeout) 
END; 

IF « a message was received from the receive dispatcher » 
THEN 

StopTimer (op A Timeout); (* Cancel the timer *) 

msg := « pass the buffer pointer »; 

op A .Address := buff A .Source; (* We're now talking to this address *) 
op A .Version := « version of received message »; 
RETURN (* Return with the message *) 

END 
END 
END DLLReceive; 

When the processing of the receive buffer is complete, it is released by a call to the Receive- 
Done routine. 

PROCEDURE DLLReceiveDone (buff: POINTER TO Buffer) 
BEGIN 

« return the buffer to the buffer pool » 
END DLLReceiveDone; 

4.11.3 Perform a single request-response exchange attempt 

This procedure is used to perform a single attempt at a request-response exchange. If the 
response to the request is received within the timeout period, that response is returned; other- 
wise an exception is raised. 

The basic request-response exchange needs as one of its inputs the MOP version number to 
use, which indicates which data link envelope (Ethernet or IEEE 802.2) will be used on LANs. 

PROCEDURE DLI.ReqResp (op: POINTER TO Operation; smsg: POINTER TO Buffer; 

VAR rmsg: POINTER TO Buffer; tmo: Time, ver: MOPVersion) 

RAISES {Timeout}; 
BEGIN 

DLI.Send (op, smsg, ver); (* Send the request *) 

DLLReceive (op, rmsg, tmo, ver) (* Wait for response or timeout *) 

END DLI.ReqResp; 



4.11 .4: "Transact" request-response exchange with retry 
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4.11.4 "Transact" request-response exchange with retry 

This procedure performs a request-response exchange with a limited number of retries. The 
retry limit is given by the architectural constant RetransmitMax. The time between retries is 
given by the Circuit characteristic Retransmit Timer. If the request does not succeed within the 
limit of the number of retries, an exception is raised. 

This procedure also selects the appropriate MOP protocol version to use if the version has 
not yet been determined. This is done by performing one attempt using version 4, then an at- 
tempt using version 3, and so on alternately until either a response arrives or the retry limit is 
exceeded. In this case, the retry limit is in effect doubled, i.e., an attempt using version 4 plus 
an attempt using version 3 counts for a single retry. Version 4 is normally tried first, but if an 
implementation has some reason to expect that version 3 is more likely to be correct, it would 
make sense to begin with that version. As an optimization, implementations may try both ver- 
sions simultaneously. For some protocol exchanges (e.g., Loop) care must be taken not to con- 
fuse the replies; the receipt number in the message can be used to do this. 

PROCEDURE DLI.Transact (op: POINTER TO Operation; smsg: POINTER TO Buffer; 

VAR rmsg: POINTER TO Buffer) 

RAISES {Timeout}; 
VAR tries: INTEGER; 
BEGIN 

FOR tries := 1 TO RetransmitMax 
DO 

IF op A .Version = Unknown (* If we don't know the protocol version yet *) 

THEN 

(* If we don't know the version, try V4, then V3; do these two steps repeatedly *) 
TRY 

DLI.ReqResp (op, smsg, rmsg, op A .CircPtr A .RetransmitTimer, V4); 
RETURN (* Return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END; 

TRY 

DLI.ReqResp (op, smsg, rmsg, op A .CircPtr A .RetransmitTimer, V3); 
RETURN (* Return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 

ELSE (* Version is known, use it *) 

TRY 

DLI.ReqResp (op, smsg, rmsg, op A .CircPtr A .RetransmitTimer, op A . Version); 
RETURN (* If it worked, return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 
END 
END; 

RAISE (Timeout) 
END DLI.Transact; 

4.11.5 Request-response with infinite retry for Request Program 

This procedure performs a request-response exchange with unlimited retries similar to the 
one shown above for DLI.MustTransact. The one shown here is intended for use with the 
Request Program message. Instead of retrying at a fixed rate, the retries are done in short 
bursts; within a burst, retries are spaced by the Circuit characteristic Retransmit Timer. If the 
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protocol version number to be used is not known, then the burst consists of a number of V4 mes- 
sages first, followed by V3 messages. This ensures that the Requester will not unintentionally 
fall back to V3 protocol if a message is lost or the server is slow in responding. As with the 
other request/response exchanges, an implementation may start with V3 and try V4 next if it 
has reason to expect V3 to be likely to be the right version. As an optimization, implementa- 
tions may try both versions simultaneously. 

The bursts in turn are spaced according to a "Backoff timer, which increases as the number 
of retries increases. To help reduce the problem of many clients transmitting requests in lock- 
step, the actual delay between bursts has a "random jitter" applied to it, which varies the delay 
by ± 25% from the backoff value. The random number generator used to control sending of pe- 
riodic SysID messages can be used for this purpose. 

The procedure returns only on successful completion of the exchange. 

Note: 

Since the retransmissions within the burst are separated by Retransmit Timer (4 
seconds by default) and the initial value of the backoff timer is equal to that, 
each node requesting load service can contribute up to 0.25 packets/second of 
load on the load server. Under certain conditions, such as restoration of power 
to a significant size LAN, the number of nodes requesting load service may be 
substantial. Therefore it is very important for load servers to process Request 
Program messages efficiently. 

In large networks, there typically will be a number of load servers, each of 
which is responsible for loading a subset of all the load clients on the LAN. This 
will help performance when there are many requests, but only if the servers can 
dismiss requests from clients that they are not set up to load in a very short 
time. Therefore, implementations should be designed to be able to dismiss re- 
quests within a few milliseconds. 

PROCEDURE DLLBackoffTransact (op: POINTER TO Operation; smsg: POINTER TO Buffer; 

VAR rmsg: POINTER TO Buffer); 
VAR backofftime, tries: INTEGER; 

tmo: Time; 
BEGIN 

backofftime := op A .CircPtr A .RetransmitTimer; 

(* Initialize backoff *) 

LOOP 

IF op A .Version = Unknown (* If we don't know the protocol version yet *) 

THEN 

(* If we don't know the version, try a burst of V4, then a burst of V3 *) 
FOR tries := 1 TO BurstSize (* Do a burst *) 
TRY 

DLI.ReqResp (op, smsg, rmsg, op A .CircPtr A .RetransmifTimer, V4); 
RETURN (* Return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 
END; 

FOR tries := 1 TO BurstSize (* Do a burst *) 
IF tries = BurstSize 
THEN 

tmo := backofftime * (0.75 + 0.5 * Random ( ) ) 

(* On last try of a burst, wait the backoff time *) 

ELSE 

tmo := op A .CircPtr A .RetransmitTimer 
END; 
TRY 
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DLI.ReqResp (op, smsg, rmsg, tmo, V3); 
RETURN (* Return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 
END 
ELSE 

FOR tries := 1 TO BurstSize (* Do a burst *) 
IF tries = BurstSize 
THEN 

tmo := backofftime * (0.75 + 0.5 * Random ( ) ) 

(* On last try of a burst, wait the backoff time *) 

ELSE 

tmo := op A .CircPtr A .RetransmitTimer 
END; 
TRY 

DLI.ReqResp (op, smsg, rmsg, tmo, op A . Version); 
RETURN (* If it worked, return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 
END 
END; 

backofftime := MIN (backofftime * 2, MaxBackoff) 
END 

END DLLBackoffTransact; 



4.11.6 Enable and disable SAP address for XID/TEST requester 

The following procedures enables and disable a SAP address on the port used by the Test or 
Query Requester. The CSMA/CD and FDDI data link architectures support the sending of XID 
and TEST frames only on ports that are opened for User Supplied LLC. A port of that type is 
opened when the circuit is enabled (see Section 4.16.1). Only the CSMA/CD data link requests 
are shown here; the ones for FDDI are identical. 

PROCEDURE LAN. EnableS AP (port: PortID; ssap: SAP Address); 
BEGIN 

CSMACD. EnableS AP (port,ssap); (* Enable the specified SAP address *) 

END LAN. EnableS AP; 

PROCEDURE LAN. Disables AP (port: PortID; ssap: SAP Address); 
BEGIN 

CSMACD. Disables AP (port,ssap); (* Disable the specified SAP address *) 

END LAN .Disables AP; 

4.11.7 Perform an XID or TEST exchange 

The procedures below handle the data link service interface calls for the Test and Query Re- 
quester. For simplicity, only the CSMA/CD calls are shown; if the data link being used is FDDI, 
then the corresponding FDDI service interface calls would be used (which take the same set of 
arguments). 

These procedures are essentially the same as the common MOP Transact and ReqResp pro- 
cedures. The only functional difference is that they exchange LLC control messages rather 
than data messages. In addition, the receive processing deals with arriving XID and TEST 
command frames, since that is required by the IEEE 802.2 LLC standard. (This is normally a 
function of the data link layer, but when a port is open in User Supplied LLC mode, those 



86 



Operation 



frames are delivered to the user and need to be handled. The actual processing is not shown; 
refer to the IEEE 802.2 standard for details.) 

PROCEDURE LAN .LLCTransact (op: POINTER TO Operation; buff: POINTER TO Buffer; LLCFC: Byte) 

RAISES {Timeout}; 
VAR tries: INTEGER; 
BEGIN 

FOR tries := 1 TO RetransmitMax 
DO 

TRY 

LAN .LLCReqResp (op, buff, LLCFC); 

RETURN (* If it worked, return to caller *) 

EXCEPT 

I Timeout: (* Keep going if no answer received *) 

END 
END; 

RAISE (Timeout) 
END LAN .LLCTransact; 

PROCEDURE LAN .LLCReqResp (op: POINTER TO Operation; 

VAR msg: POINTER TO Buffer; LLCFC: Byte); 

RAISES {Timeout}; 
VAR i: INTEGER; 

detail: CSMACD.ReceiveErrorDetail; 

src, dest: LAN Address; 

form: CSMACD.FormatAndMux; 

b: BOOLEAN; 

fcs: CSMACD.FCSValue; 
BEGIN 

LAN.LLCSend (op, msg); (* Send the request *) 

StartTimer (op A Timeout, op A RetransmitTimer); 

LOOP 

CSMACD .Receive (op\CircPtr\LLCport, FALSE, msg, i) 
LOOP 

IF Expired (op A Timeout) 

THEN 

CSMACD.ReceiveAbort(op A .CircPtr A .LLCport) 

RAISE (Timeout) 
END; 
TRY 

CSMACD.ReceivePoll (op A .CircPtr A .LLCport, detail, dest, src, form, msg, i, b, fcs); 
EXIT (* Receive completed, handle it *) 

EXCEPT 

I NotComplete: (* Keep going if nothing received yet *) 

END 
END; 

IF msg A . Data[l] MOD 2 = (* If it's a Command frame *) 

THEN 

CASE msg A .Data[2] OF (* Dispatch on the LLC FC field *) 

LLCTEST: (* TEST *) 

CSMACD .TestResponse (op A .CircPtr A .LLCport, msg) 
I LLCXID: (*XID*) 

CSMACD .XIDResponse (op A .CircPtr\LLCport, msg) 
I ELSE 

(* Ignore any other frames *) 
END 

ELSEIF msg\Data[2] = LLCFC 

THEN (* If a response, is this the one we're waiting for? *) 



4.12: Receive dispatchers 



87 



StopTimer (op A .Timeout); (* Cancel the receive timeout *) 

RETURN (* ... and we're done *) 

END 
END 

END LAN .LLCReqResp; 

PROCEDURE LAN.LLCSend (op: POINTER TO Operation; msg: POINTER TO Buffer); 

VAR form: CSMACD.FormatAndMux; 

BEGIN 

form .format := IEEE; 

CSMACD Transmit (op A .CircPtr\LLC, op A .Address, op A .CircPtr A .DataLinkAddress, form, msg); 
LOOP 
TRY 

CSMACD TransmitPoll (op\CircPtr A .LLC, msg); 
EXIT 
EXCEPT 

I NotComplete: (* Keep going if not done yet *) 

END 
END 

END LANLLCSend; 



4.12 Receive dispatchers 

The receive dispatcher examines packets received from the data link layer and dispatches 
them to the appropriate processing thread. The rules by which the correct thread is chosen de- 
pend on the data link type. The sections below define the receive dispatcher algorithms in de- 
tail. 

4.12.1 Receive dispatcher for point to point data links 

In the case of point to point data links, the dispatching decision is based simply on the MOP 
message function code (the first byte of the MOP message). If there is a processing thread wait- 
ing for the message (i.e., it is in the DLI.Receive routine) then it is given the message. If not, 
then the message is ignored. 

The dispatching rules are as follows: 

1. If the message is a Looped Data message, it goes to the loop requester. 

2. If the message is a Loop Data message, and the loop requester is active on the circuit, 
the message goes to the loop requester. If not, it goes to the loop server. (The reason for 
this peculiar rule is that Loop Data messages may be sent out by a loop requester and 
be looped back by a passive loopback connector. For that case they have to be treated as 
responses.) 

3. If the message is a Memory Load, Memory Load with Transfer Address, or Parameter 
Load with Transfer Address message, it goes to the load requester. 

4. If the message is a Request Program or Request Memory Load message, it goes to the 
load server. 

5. If the message is a Boot message, it goes to the console server. 



6. 



If the message is a Request Dump Data or Dump Complete message, it goes to the 
dump requester. 
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7. If the message is a Request Dump Service or Memory Dump Data message, it goes to 
the dump server. 

8. Any other message, including a message with undefined message function codes, is qui- 
etly ignored. 

4.12.2 Receive dispatcher for LAN data links 

In the case of LAN data links, the dispatching decision can be based on a number of factors: 

• MOP message function code (the first byte of the MOP message) 

• Protocol Identifier (Protocol Type for Ethernet format messages), or DSAP address in 
the case of XID and TEST responses 

• Source address 

• MOP version (as implied by the data link envelope: Ethernet format packets are V3, 
802.2 format packets are V4) 

If there is a processing thread waiting for the message (i.e., it is in the DLI.Receive routine) 
then it is given the message. If not, then the message is ignored. 

When the message pertains to an operation that is in progress (as opposed to one just being 
initiated), the search for a matching processing thread includes a comparison of the message 
source address with the operation's remote station address. In those cases the version number 
of the message is also checked against what was expected; if the two do not match the message 
is quietly ignored. 

When the message pertains to an operation that is just being initiated, reception of a re- 
sponse establishes the remote station address and version for this operation. (See DLI.Receive, 
Section 4.11.2). 

The dispatching rules are as follows: 

1. If the Protocol Identifier is the Loop Protocol ID: 

a. If the message is a Reply message, it goes to the loop requester. 

Note: it is not correct to check the message source address against the address of 
the loop target in this case, since the last hop of the loop may have been an assis- 
tant. One solution is to check against either the target address or the assistant 
address depending on the assistance type; another approach is not to permit multi- 
ple concurrent loop requester operations on the same circuit. 

b. If the message is a Forward Data message, it goes to the loop server. 

2. If the Protocol Identifier is the Load Protocol ID: 

a. If the message is an Assistance Volunteer message, it goes to the load requester or 
the dump requester. 

(Presumably the load requester and dump requester are never simultaneously ac- 
tive, otherwise it would be impossible to decide which of the two receives the Assis- 
tance Volunteer message.) 

b. If the message is a Memory Load, Memory Load with Transfer Address, or Pa- 
rameter Load with Transfer Address message and the message source address 
matches, the message goes to the load requester. 



4. 12.2: Receive dispatcher for LAN data links 



89 



Special case: if a load of the Secondary Loader is being requested from the Load 
Assistance multicast address, then the address check is omitted. (For the Secon- 
dary Loader, the server sends the data immediately rather than sending an Assis- 
tance Volunteer message first.) 

c. If the message is a Request Program, it goes to the load server. If there is a load 
server thread waiting for a Request Program message from this remote station 
(i.e., because it is processing a Load directive addressed to that station) the mes- 
sage is delivered to that thread. 

d. If the message is a Request Memory Load message and the message source ad- 
dress matches, the message goes to the corresponding load server. 

e. If the message is a Request Dump Data or Dump Complete message and the mes- 
sage source address matches, the message goes to the dump requester. 

f. If the message is a Request Dump Service message, it goes to the dump server. 

g. If the message is a Memory Dump Data message and the message source address 
matches, it goes to the corresponding dump server. 

3. If the Protocol Identifier is the Console Protocol ID: 

a. If the message is a Request System ID, Request Counters, Reserve Console, or 
Boot message, it goes to the console server. 

b. If the message is a Console Command or Release Console message and the mes- 
sage source address matches the circuit console user address, the message goes to 
the console server. 

c. If the message is a System ID, CSMA/CD Counters, Other Counters, or Console 
Response message and the message source address matches, the message goes to 
the corresponding console requester. 

d. If the message is a System ID message, it goes to the configuration monitor. 

Note: 

The two rules above are somewhat in conflict since a System ID message 
could pass both checks (if it comes from the console carrier target and the 
configuration monitor function is active). In that case, the message could 
be passed to both functions, or alternatively the periodic System ID mes- 
sage (which is sent to the Console multicast address and has a receipt 
number of zero) could go to the configuration monitor and the other to the 
Console Requester. 

4. If the message is an 802.2 TEST response message and the message source address 
matches, the message goes to the corresponding Test requester. 

5. If the message is an 802.2 XID response message and the message source address 
matches, the message goes to the corresponding Query requester. 

6. Any other message, including a message with an undefined message type code, is qui- 
etly ignored. 

Note that MOP has two open data link ports per circuit (or more when doing a Test or Query 
directive), due to the way the data link layer abstract service interface is defined. The distinc- 
tion of which port carried the message is ignored in the rules above. 
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4.13 DDCMP specific algorithms 

The following procedures specify the data link dependent details of using DDCMP data links 
with MOP. 

The DDCMP architecture does not have a formal service interface definition as the other 
data link architectures do. The code below is written as if such interfaces did exist. The intent 
of each interface call is clarified by context and comments. 

4.13.1 Exclusive maintenance mode 

The DDCMP data link is unique among the data links supported by MOP in that it has "ex- 
clusive maintenance". This means that the data link service needed by MOP is available from 
DDCMP only when the normal (sequential, connection oriented) service is not active. All other 
data links allow both services to be used concurrently. Because of this property, additional 
steps are needed in the DDCMP specific algorithms to force the data link into the proper state. 

Since the DDCMP spec does not have a formally defined service interface, the algorithms be- 
low use an assumed set of services. In particular: 

• The type of service desired (in this case, maintenance mode) is stated on the Open call. 

• Open and Close work independent of the current mode. 

• The receive calls work independent of the current mode, but the receive will not com- 
plete until the data link is in maintenance mode and a maintenance mode message is 
received. Any normal mode traffic is invisible. 

The DDCMP data link layer enters maintenance mode for two reasons: 

1. A request is made to enter maintenance mode via the client interface. Subsequent 
transmit requests by that client are done as DDCMP Maintenance format messages. 

2. A DDCMP Maintenance Mode message is received. 

When DDCMP enters maintenance mode, normal (connection oriented) service is termi- 
nated. To restore normal mode service, a client using that service (e.g., the Routing layer) must 
close and reopen its port. 

Synchronization between MOP and any normal mode DDCMP client is not shown here in 
detail. In outline, the necessary steps are: 

1. When initiating a request (e.g., from the Dump Client), MOP must tell DDCMP to enter 
maintenance mode. The circuit remains in maintenance mode until the operation is fin- 
ished, at which time it can be restarted in normal mode. 

2. When responding to a requests (e.g., in the Load Server), DDCMP has entered mainte- 
nance mode due to the receipt of a Maintenance format message. The circuit remains in 
maintenance mode until the operation is finished. It may then be restarted in normal 
mode. 

4.13.2 Open 

The Open procedure opens a port for MOP on the circuit, and sets up all the necessary oper- 
ating parameters. 



PROCEDURE DLD.DDCMP_Open (circ: POINTER TO Circuit) 



4.13.3: Close 
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RAISES {DLD.CommonExceptions} 
VAR portname: LocalEntityName; 
BEGIN 

DDCMP.OPEN (circ A .Name, 
circ A .LinkName, 
Maintenance, 
262, 

portname, 
circ A .mopport, 
circ A .SDUsize) 
END DLD.DDCMP_Open; 



(* Holds returned PortName *) 

(* Use our identifier for "name" *) 

(* "Station" to open *) 

(* Make this a "Maintenance" type port *) 

(* Minimum acceptable buffer size *) 

(* Scratch variable to receive port name *) 

(* Return port ID here *) 

(* Buffer size available on this port *) 



4.13.3 Close 



The Close procedures closes the MOP port on the circuit that was previously opened by the 
Open procedure. 

PROCEDURE DLD.DDCMP_Close (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
BEGIN 

DDCMP .CLOSE (circ A .mopport); (* Call data link to close the port *) 

circ A .mopport := NIL 
END DLD.DDCMP_Close; 



4.13.4 Transmit functions 



The following are the transmit related data link specific functions for the DDCMP data link. 

PROCEDURE DLD.DDCMP_Transmit (op: POINTER TO Operation; msg: POINTER TO Buffer; 

ver: MOPVersion) RAISES {DLD.CommonExceptions} 
BEGIN 

DDCMP Transmit (op A .CircPtr A .mopport, msg) 
END DLD.DDCMP_Transmit; 



PROCEDURE DLD.DDCMP_TransmitPoll (op: POINTER TO Operation; msg: POINTER TO Buffer) 

RAISES {DLD.CommonExceptions} 
BEGIN 

DDCMP TransmitPoll (op A .CircPtr A .mopport, msg) 
END DLD.DDCMP_TransmitPoll; 



4.14 HDLC specific algorithms 

The following procedures specify the data link dependent details of the operation of MOP 
over the HDLC data link. Unlike DDCMP, the HDLC data link supports "concurrent" mainte- 
nance operation, i.e., MOP can use the data link independent of other users of the data link. 
This is done by using the Unsequenced Data service of HDLC, which offers a datagram commu- 
nication mechanism independent of the sequenced (virtual circuit) data service. (If a node 
needs only MOP, for example in primitive state, it suffices to implement just the unsequenced 
service of the HDLC data link, and omit the sequenced service support entirely.) 

Detailed descriptions of the HDLC data link services used in this section may be found in the 
HDLC Data Link architecture specification. 



92 



Operation 



4.14.1 Open 



The Open procedure opens a port for MOP on the circuit, and sets up all the necessary oper- 
ating parameters. 



PROCEDURE DLD.HDLC_Open (circ: 
RAISES {DLD.CommonExceptions 
VAR portname: LocalEntityName; 
BEGIN 

HDLC.OPEN (circ\Name, 
circ A .LinkName, 
Unsequenced, 
MOPProtocolID, 
262, 

portname, 
circ A .mopport, 
circ A .SDUsize) 
END DLD.HDLC_Open; 



POINTER TO Circuit) 
} 

(* Holds returned PortName *) 

(* Use our identifier for "name" *) 
(* "Station" to open *) 
(* Ask for unsequenced service *) 
(* Use the HDLC MOP protocol ID *) 
(* Minimum acceptable buffer size *) 
(* Scratch variable to receive port name *) 
(* Return port ID here *) 
(* Buffer size available on this port *) 



4.14.2 Close 



The Close procedures closes the MOP port on the circuit that was previously opened by the 
Open procedure. 

PROCEDURE DLD.HDLC_Close (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
BEGIN 

HDLC.CLOSE (circ A .mopport); (* Call data link to close the port *) 

circ A .mopport := NIL 
END DLD.HDLC_Close; 



4.14.3 Transmit functions 



The following are the transmit related data link specific functions for the HDLC data link. 
Note that the Transmit is done using the Unsequenced mode of HDLC. 

PROCEDURE DLD.HDLC_Transmit (op: POINTER TO Operation; msg: POINTER TO Buffer; 

ver: MOPVersion) RAISES {DLD.CommonExceptions} 
BEGIN 

HDLC TransmitUnsequenced (op A .CircPtr A .mopport, msg) 
END DLD.HDLC_Transmit; 

PROCEDURE DLD.HDLC_TransmitPoll (op: POINTER TO Operation; msg: POINTER TO Buffer) 

RAISES {DLD.CommonExceptions} 
BEGIN 

HDLC TransmitPollUnsequenced (op A .CircPtr A .mopport, msg) 
END DLD.HDLC_TransmitPoll; 



4.15 LAPB specific algorithms 

This section describes the data link specific aspects of using the LAPB data link. Since 
LAPB is a variant of HDLC, there is a lot of similarity with the HDLC section. There are some 
differences to account for the different service interfaces of the two data links. 



4.15.1: Open 
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LAPB is normally used as the data link protocol in connections to the X.25 public packet 
switched network. MOP obviously has no place in such connections. Therefore, on LAPB cir- 
cuits MOP is only used for loop testing; this should only be done when the line has previously 
been set into some form of loopback mode or otherwise has been disconnected from the public 
network. 



4.15.1 Open 



The Open procedure opens a port for MOP on the circuit, and sets up all the necessary oper- 
ating parameters. 



PROCEDURE DLD.LAPB_Open (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
VAR portname: LocalEntityName; 
BEGIN 

LAPB .OPEN (circ A .Name, 
circ A .LinkName, 
Unsequenced, 
262, 

portname, 
circ A .mopport, 
circ A .SDUsize) 
END DLDLAPB_0pen; 



(* Holds returned PortName *) 

(* Use our identifier for "name" *) 
(* "Station" to open *) 
(* Ask for unsequenced service *) 
(* Minimum acceptable buffer size *) 
(* Scratch variable to receive port name *) 
(* Return port ID here *) 
(* Buffer size available on this port *) 



4.15.2 Close 



The Close procedures closes the MOP port on the circuit that was previously opened by the 
Open procedure. 

PROCEDURE DLD.LAPB_Close (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
BEGIN 

LAPB .CLOSE (circ A .mopport); (* Call data link to close the port *) 

circ A .mopport := NIL 
END DLD.LAPB_Close; 



4.15.3 Transmit functions 



The following are the transmit related data link specific functions for the LAPB data link. 
Note that the Transmit is done using the Unsequenced mode of LAPB. 

PROCEDURE DLD.LAPB_Transmit (op: POINTER TO Operation; msg: POINTER TO Buffer; 

ver: MOPVersion) RAISES {DLD.CommonExceptions} 
BEGIN 

LAPBTransmitUnsequenced (op A .CircPtr A .mopport, msg) 
END DLD.LAPB_Transmit; 

PROCEDURE DLD.LAPB_TransmitPoll (op: POINTER TO Operation; msg: POINTER TO Buffer; 

ver: MOPVersion) RAISES {DLD.CommonExceptions} 
BEGIN 

LAPB TransmitPollUnsequenced (op A .CircPtr A .mopport, msg) 
END DLD.LAPB_TransmitPoll; 
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4.16 CSMA/CD specific algorithms 



The following procedures specify the data link dependent details of the operation of MOP 
over the CSMA/CD (Ethernet and IEEE 802.3) data link. 

The CSMA/CD service procedures called (module name CSMACD) are defined in the services 
chapter of the CSMA/CD Data Link architecture. For convenience, we will treat them as proce- 
dures that signal any errors (rather than as functions that return a value indicating success or 
failure). 



4.16.1 Open 



This procedure shows how MOP sets up the data link ports for its use. This is done when 
MOP begins to perform its tasks. The equivalent setup, such as protocol and multicast address 
setup, is also necessary whenever the set of enabled functions is changed (via the Enable and 
Disable management directives); that detail is not shown here. 

PROCEDURE DLD .CSM ACD_Open (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
VAR portname: LocalEntityName; (* Holds returned PortName *) 

BEGIN 

CSMACD .OpenPort (circ A .Name, (* Use our identifier for "name" *) 

circ A .LinkName, (* "Station" to open *) 

Class 1, (* Use Class 1 LLC service *) 

TRUE, (* Use "padded" form for Ethernet frames *) 

circ A .mopport, (* Return port ID here *) 

portname); (* Scratch variable to receive port name *) 

CSMACD .EnableProtocolType (circ A .mopport, ConsoleProtocolType); 

(* Enable protocol type *) 
CSMACD .EnableProtocolID (circ A .mopport, ConsoleProtocolID); 

(* and corresponding Protocol ID *) 
IF LoadServer IN circ A .Functions OR (* If the Load/Dump functions are enabled... *) 

LoadClient IN circ A .Functions OR 

DumpServer IN circ A .Functions OR 

DumpClient IN circ A .Functions (* ... then its Protocol Type is enabled *) 

THEN 

CSMACD .EnableProtocolType (circ A .mopport, LoadProtocolType); 
CSMACD .EnableProtocolID (circ A .mopport, LoadProtocolID) 
END; 

IF LoadServer IN circ A .Functions OR (* If the Load/Dump server is enabled... *) 

DumpServer IN circ A .Functions (* ... then enable the assistant multicast address *) 

THEN 

CSMACD .EnableMACAddress (circ A .mopport, LoadAssistant) 
END; 

CSMACD .OpenPort (circ A .Name, (* Use our identifier for "name" *) 

circ A .LinkName, (* "Station" to open *) 

Class 1, (* Use Class 1 LLC service *) 

FALSE, (* Do not use "padded" form for Ethernet frames *) 

circ A .loopport, (* Return port ID here *) 

portname); (* Scratch variable to receive port name *) 

CSMACD .EnableProtocolType (circMoopport, LoopProtocolType); 

(* Enable protocol type *) 

CSMACD .EnableProtocolID (circMoopport, LoopProtocolID); 

(* and corresponding procol ID *) 

(* optionally: *) 

CSMACD .EnableMACAddress (circMoopport, LoopAssistant) 
(* end *) 



4.16.2: Close 
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CSMACD.OpenPort (circ\Name, (* Use our identifier for "name" *) 

circ A .LinkName, (* "Station" to open *) 

UserSupplied, (* Need user LLC to issue XID or TEST frames *) 

FALSE, (* "padded" is irrelevant for this port *) 

circ A .LLCport, (* Return port ID here *) 

portname); (* Scratch variable to receive port name *) 

(* Note that we enable no SAP (or anything else) at this time, so this port is for the moment unused *) 

circ A .DataLinkAddress := « the MAC address for this data link »; 

circ\SDUSize := 1492; (* 802.2 SNAP PDU size *) 

END DLD.CSMACD_Open; 

4.16.2 Close 

The Close procedures closes the ports on the circuit that were previously opened by the Open 
procedure. 

PROCEDURE DLD.CSMACD_Close (circ: POINTER TO Circuit) 

RAISES {DLD.CommonExceptions} 
BEGIN 

CSMACD .Close (circ A .loopporf); (* Call data link to close the loop port *) 

circ A .loopport := NIL; 

CSMACD .Close (circ A .mopport); (* ... and the other port *) 

circ A .mopport := NIL 
END DLD. CSMACD Close; 



4.16.3 Transmit functions 

The following are the transmit related data link specific functions for the CSMA/CD data 
link. The major issue here is the selection of the correct SNAP Protocol ID or Ethernet Protocol 
Type, according to the protocol version being used and the specific message being transmitted. 

PROCEDURE DLD .CSM ACD_Transmit (op: POINTER TO Operation; msg: POINTER TO Buffer; 

ver: MOPVersion) RAISES {DLD.CommonExceptions} 
BEGIN 

IF ver = V4 

THEN (* Set up the correct Protocol ID *) 

msg A .LANFormat.format := SNAP; 
IF op A .OpType IN {LoopRequester, LoopServer} 
THEN msg A .LANFormat.ProtID := LoopbackProtocolID 

ELSEIF msg A .Data[0] IN {MemLoadTA, DumpComplete, MemLoad, Assistance, RequestDump, 

RequestProgram, RequestLoad, RequestDumpService, 
DumpData, ParameterLoad} 

THEN msg A .LanFormat.ProtID := LoadProtocolID 

ELSE msg A .LanFormat.ProtID := ConsoleProtocolID 

END 

ELSE (* V3 format, set up correct Protocol Type *) 

msg A .LANFormat .format := Ethernet; 
IF op A .OpType IN {LoopRequester, LoopServer} 
THEN msg A .LANFormat.type := LoopbackProtocolType 

ELSEIF msg A .Data[0] IN {MemLoadTA, DumpComplete, MemLoad, Assistance, RequestDump, 

RequestProgram, RequestLoad, RequestDumpService, 
DumpData, ParameterLoad} 

THEN msg A .LanFormat.type := LoadProtocolType 

ELSE msg A .LanFormat.type := ConsoleProtocolType 

END 
END; 

msg A .Source := op A .CircPtr A .DataLinkAddress; 
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IF op A .OpType IN {LoopRequester, LoopServer} 
THEN 

CSMACD .Transmit (op A .CircPtr A .loopport, msg A .Destination, msg A .Source, 
msg A .LANFormat, msg) 

ELSE 

CSMACD Transmit (op A .CircPtr A .mopport, msg A .Destination, msg A .Source, 
msg A .LANFormat, msg) 

END 

END DLD.CSMACD_Transmit; 

PROCEDURE DLD .CSM ACD_TransmitPoll (op: POINTER TO Operation; msg: POINTER TO Buffer) 

RAISES {DLD.CommonExceptions} 
BEGIN 

IF op A .OpType IN {LoopRequester, LoopServer} 
THEN 

CSMACD .TransmitPoll (op A .CircPtr A .loopport, msg) 
ELSE 

CSMACD .TransmitPoll (op A .CircPtr A .mopport, msg) 
END 

END DLD.CSMACD_TransmitPoll; 



4.17 FDDI specific algorithms 

The FDDI specific algorithms are identical to those specified for CSMA/CD, except that the 
service interface calls of the FDDI Data Link architecture specification is used. These offer the 
same semantics as the service interface calls of the CSMA/CD Data Link. Note that the maxi- 
mum data link SDU size is 1492, even though FDDI allows larger frames. This ensures that 
communication across LAN bridges will work. 

4.18 Miscellaneous data link independent procedures 

The procedures in this section are miscellaneous utility procedures used in the Modular- 
Plus descriptions of the MOP algorithms. These are independent of the data link being used. 

4.18.1 Resource allocation/deallocation 

These procedures allocate and deallocate resources used by MOP operation threads. 

PROCEDURE DLLAlloc (VAR op: POINTER TO Operation; VAR buff: POINTER TO Buffer) 

RAISES {InsufficientResources}; 
BEGIN 

NEW (buff); 

NEW (op); 

« insert the new Operation record in the list of active operations » 
END DLLAlloc; 

PROCEDURE DLIFree (op: POINTER TO Operation; buff: POINTER TO Buffer); 
BEGIN 

« remove Operation record from the list of active operations »; 
FREE (buff); 
FREE (op) 
END DLIFree; 



4. 1 8.2: Manipulate fields in the buffer contents 
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4.18.2 Manipulate fields in the buffer contents 

The procedures below are used in the Modula-2-Plus algorithm descriptions to examine or 
load fields in message buffers. 

PROCEDURE DLI.Getlnteger (buff: POINTER TO Buffer; off: INTEGER) : INTEGER; 

« return the value of the 16-bit integer whose low order byte is at the specified offset, and high order byte 

at the byte following that in the buffer. » 
END DLI.Getlnteger; 

PROCEDURE DLLPutlnteger (buff: POINTER TO Buffer; off: INTEGER; value: INTEGER); 

« store the 16-bit integer (value), with low order byte at the specified offset and high order byte at the byte 

following that, into the buffer. » 
END DLLPutlnteger; 

PROCEDURE DLI.GetLong (buff: POINTER TO Buffer; off: INTEGER) : INTEGER; 

« return the value of the 32-bit integer whose low order byte is at the specified offset, and higher order 

bytes at the 3 bytes following that in the buffer. » 
END DLI.GetLong; 

PROCEDURE DLI.PutLong (buff: POINTER TO Buffer; off: INTEGER; value: INTEGER); 

« store the 32-bit integer (value), with low order byte at the specified offset and higher order bytes at the 3 

bytes following that, into the buffer. » 
END DLLPutLong; 

PROCEDURE DLI.GetAddress (buff: POINTER TO Buffer; off: INTEGER) : LANAddress; 

« return the value of the 6-byte LAN address whost first byte is at the specified offset in the buffer. » 
END DLI.GetAddress; 

PROCEDURE DLLPutAddress (buff: POINTER TO Buffer; off: INTEGER; value: LANAddress); 

« store the 6-byte LAN address (value), with its first byte at the specified offset, into the buffer. » 
END DLLPutAddress; 

4.18.3 Find a Client record 

These are the procedures that find a Client record, i.e., an entry in the Client database. 
There are three ways to get an entry: 

1. By name — this is simply a search for a Client record whose Name attribute matches 
the supplied name. This case applies for management requests where the directive 
specifies the name of the Client record to use. 

2. By circuit — here we know what circuit is to be used, and we need to find the Client 
record to use. This case applies to server functions, which use the Client record to find 
out how to respond to a received request message. 

Note that it is possible to have multiple matches (more than one Client record satisfies 
the search criteria). In that case any of the matching Client records may be used. This 
is usually undesirable; the network manager should take care to avoid such client data- 
base setups. 

There are two variants of lookup by circuit: 

a. Lookup by circuit and address — this searches for a Client record whose Circuit at- 
tribute points to the circuit in question and, for a LAN, with an Addresses attrib- 
ute value that contains the specified address. (For point to point circuits the 
match is by Circuit only.) 
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b. Lookup by circuit and device type — this searches for a Client record whose Circuit 
attribute points to the specified circuit and a Device Types attribute that contains 
the specified device type. (This variant is not used for point to point circuits.) 

PROCEDURE DLI.FindClientByName(cl: SimpleName) : POINTER TO Client 

RAISES {UnrecognizedClient} 
BEGIN 

« return a pointer to the Client entity whose Name field equals the name in the cl argument » 
END DLLFindClientByName; 

PROCEDURE DLLFindClientByCircAddr (cir: POINTER TO Circuit; addr: LANAddress) 

: POINTER TO Client; 
BEGIN 

« return a pointer to a matching Client entity, or NIL if no such entity exists. » 
END DLLFindClientByCircAddr; 

PROCEDURE DLLFindClientByCircDev (cir: POINTER TO Circuit; dev: DevType) : POINTER TO Client; 
BEGIN 

« return a pointer to a matching Client entity, or NIL if no such entity exists. » 
END DLLFindClientByCircDev; 

4.18.4 Find a Circuit record 



PROCEDURE DLI.FindCircuitByName(cir: SimpleName) : POINTER TO Circuit 

RAISES {UnrecognizedCircuit} 
BEGIN 

« return a pointer to the Circuit entity whose Name field equals the name in the cir argument » 
END DLLFindCircuitByName; 

4.18.5 Pick a Source SAP address 

The Source SAP used in Test and XID requests is selected in an implementation specific 
fashion. Unfortunately, there is no standard SAP address assigned for the purpose we need 
here. Therefore the SSAP has to be a "locally administered" value. We can't pick one architec- 
turally, since locally administered values are selected by the local network manager, not by 
Digital architects. Therefore the only way out is for the implementation to select a value dy- 
namically. 

Any value is acceptable provided that it is: 

1 . Not currently in use on the circuit, and 

2. An individual SAP (low order bit is zero), and 

3. A locally administered SAP (second bit zero), and 

4. Not the null SAP (i.e., not the all-zero SAP address) 

5. It may also be a good idea to avoid SAP address values that other vendors have archi- 
tecturally assigned to their proprietary protocols 

PROCEDURE LAN.SelectaSAP (op: POINTER TO Operation) : SAPAddress; 
BEGIN 

RETURN « a suitable SAP address » 
END LAN.SelectaSAP; 
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Messages 



This chapter defines the binary formats of the protocol messages that support the operation 
described in the operation chapter. In order to operate correctly on exclusive maintenance 
channels, message identification codes are taken from a single space. Values 16 and 18 are re- 
served obsolete values. Some data links have a minimum message size and many of the main- 
tenance protocol messages are quite small. Padding must be requested from the particular data 
link on the assumption that such a service is provided if needed. The actual size of received 
messages is also provided by the Data Link Layer, so that messages with a single variable 
length data field need not include a size field. 

The following notation is used to describe the messages: 

FIELD (LENGTH) : CODING = 

Description of field 

Where: 

FIELD is the name of the field being described. 

LENGTH is the length of the field expressed as one of the following: 

• The number of 8-bit bytes. 

• The notation "C— n" meaning counted image field with n being the maximum length in 
8-bit bytes of the image. The first byte of the field specifies the number of bytes in the 
remainder of the field. Therefore, the minimum total length of the field is one byte. 
The first byte of the field may contain information in addition to the count. 

Note that the maximum length includes the one byte field that contains the count. 
Therefore, the count byte of a C-n field can have a value in the range to n— 1, indicat- 
ing to n-l additional bytes of data follow the count byte. 

• The notation "J— n" meaning image field with n being the maximum length in 8-bit bytes 
of the image. The image is preceded by sufficient information to compute the length of 
the field. Image fields are variable length and may be null (length=0). All 8 bits of each 
byte may be used as information bits. 

• An asterisk (*), indicating that the field consists of the remainder of the message, i.e., 
the total message length less the length of all of the other fields. 

CODING is the representation type used, as follows: 



100 



Messages 



• B — Binary 

• BM — Bit map (each bit has independent meaning) 

• A — ASCII 

• Null — Interpretation depends on data representation 
Notes: 

• All numeric values are shown in decimal unless otherwise noted. 

• Fields are transmitted in the order shown, left to right. 

• All fields are transmitted low-order or least significant byte first unless otherwise speci- 
fied. 

• Bits in a field are numbered from to n where is the low-order or least-significant bit. 

• In the packet formats shown below, fields shown in dashed boxes are optional or are 
present only in certain cases. 

A summary of the defined message codes and the associated MOP functional component and 
NI Protocol Type (last two bytes of Protocol ID) is shown in Table 16 below. 



5. 1 : Downline Load messages 
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Table 16: Summary of MOP message codes 



Message code 


Message Name 


Protocol 
Type 


Protocol Name 


Section 





Memory Load with Transfer Address 


60-01 


Dump/Load 


5.1.4 


1 


Dump Complete 


60-01 


Dump/Load 


5.2.4 


2 


Memory Load 


60-01 


Dump/Load 


5.1.5 


3 


Assistance Volunteer 


60-01 


Dump/Load 


5.1.2 


4 


Request Memory Dump 


60-01 


Dump/Load 


5.2.2 


5 


Request ID 


60-02 


Console 


5.5.2 


6 


Boot 


60-02 


Console 


5.5.1 


7 


System ID 


60-02 


Console 


5.5.3 


8 


Request Program 


60-01 


Dump/Load 


5.1.1 


9 


Request Counters 


60-02 


Console 


5.5.4 


10 


Request Memory Load 


60-01 


Dump/Load 


5.1.3 


11 


Counters (CSMA/CD only) 


60-02 


Console 


5.5.5 


12 


Request Dump Service 


60-01 


Dump/Load 


5.2.1 


13 


Reserve Console 


60-02 


Console 


5.5.7 


14 


Memory Dump Data 


60-01 


Dump/Load 


5.2.3 


15 


Release Console 


60-02 


Console 


5.5.10 


16 


Reserved 


17 


Console Command and Poll 


60-02 


Console 


5.5.8 


18 


Reserved 


19 


Console Response and Acknowledge 


60-02 


Console 


5.5.9 


20 


Parameter Load with Transfer Address 


60-01 


Dump/Load 


5.1.6 


21 


Counters (other than CSMA/CD) 


60-02 


Console 


5.5.6 


24 


Point to Point Loop Data 


N/A 


Loop Test 


5.3.1 


26 


Point to Point Looped Data 


N/A 


Loop Test 


5.3.2 


1 


LAN Loop Reply 


90-00 


Loop Test 


5.4.1 


2 


LAN Loop Forward Data 


90-00 


Loop Test 


5.4.2 



5.1 Downline Load messages 

The messages described in this section relate to the MOP Load/Dump components, for the 
Downline Load service. On LANs, they are sent using the Load/Dump Protocol ID (08-00-2B- 
60-01). 
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5.1.1 Request Program 

The Request Program message consists of: 





DEVICE 


FORMAT 


PROGRAM i 


CODE 


TYPE 


VERSION 


TYPE ! 



' SOFTWARE I 



ID 



PROCESSOR i 
I L 



OTHER i 

info ; 



Figure 5: Request Program message format 



Where: 
CODE(1):B = 



The number 8. 



DEVICE TYPE (1) : B = The device type at the requesting system. Used by the load server to 
search for a client database entry by device type. Defined device types 
are found in Appendix A. 1 . 

FORMAT VERSION (1) : B = The protocol format version. For version 4.0, the value is 4. 

PROGRAM TYPE (1) : B = The generic type of program being requested. The defined values are 
as follows: 



Value 


1 

2 
3 
4 



Meaning 

Secondary loader 
Tertiary loader 
System Image 
Management image 
CMIP Script file 



This field and all the following can be omitted, in which case the default 
for this field is 0. A system image is whatever is to end up in the 
requesting system, and could be any type of program. A management 
image indicates information that is specific to an individual requesting 
system, while the system program in this context refers to a generic 
software product that can run in any system of a particular type. 

SOFTWARE ID (C-128) : = Identification of the software being requested. Omitted if 
PROGRAM TYPE is omitted. The format is the same as defined for the 
Boot message (Section 5.5.1). Note that Software ID codes of -1 
(standard operating system) and -2 (maintenance system) are 
meaningful only for Program Type = 2 (System Image) 

PROCESSOR (1) : B = The processor to be loaded. This field is used to distinguish a 
communications "front end" processor on a system where it is 
independent of the main CPU. 

Value Meaning 

System processor 

1 Communication processor 

OTHER INFO (*) : = Further information to identify the requesting system. Definition is as 
described for the Remote Console System ID message (Section 5.5.3). 



The primary use of this field is for the DATA LINK BUFFER SIZE 
parameter. Implementations are strongly encouraged to supply this 



5.1.2: Assistance Volunteer 
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field, since the load server will otherwise assume a buffer size of 262, 
resulting in much reduced performance. 

Note: some implementations include the Device Type item in this field. 
Since that information is provided already in the DEVICE TYPE field, 
including it here is redundant. For compatibility with certain existing 
implementations that have different values in the two fields, a Load 
Server shall use only the DEVICE TYPE field and not any Device Type 
item included in the Other Info field. However, conforming 
implementations shall send consistent requests. (The recommended 
practice is to send the Device Type only in the Device Type field; 
optionally, the Device Type may additionally be sent in the OTHER 
INFO field, but it must then be the same value in both places.) 

5.1.2 Assistance Volunteer 

The Assistance Volunteer message consists of: 



CODE 



Figure 6: Assistance Volunteer message format 

Where: 

CODE (1 ) : B = The number 3. 

5.1.3 Request Memory Load 

The Request Memory Load message consists of: 



CODE 



LOAD 
NUMBER 



RESERVED 



Where: 



CODE (1) : B = 



Figure 7: Request Memory Load message format 



The number 10. 



LOAD NUMBER (1) : B = The number of the load segment being requested, as defined for the 
Memory Load with Transfer Address message (Section 5.1.4). 

RESERVED (1 ) : B = A reserved byte. Send 0; ignore on receipt. 

Note: for compatibility with certain existing implementations, load 
servers shall accept Request Memory Load messages where this field is 
missing. However, all conforming implementations shall send this 
field. 



5.1.4 Memory Load with Transfer Address 



The Memory Load with Transfer Address message consists of: 
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CODE 


LOAD 


LOAD 1 


IMAGE 


TRANSFER 


NUMBER 


ADDRESS ! 


DATA 


ADDRESS 



Figure 8: Memory Load with Transfer Address message format 



Where: 



CODE (1) : B = 
LOAD NUMBER (1) 



The number 0. 

B = The load number for multi-segment loads. This message may be 
preceded by Memory Load without transfer address messages. The load 
number starts at zero and is incremented for each load message sent in 
a loading sequence. The load number is modulo 256. After load 
number 255 is load number 0. 

LOAD ADDRESS (4) : B = The memory load address (physical) for storage of the data image. 

IMAGE DATA (*) : = The image to be stored into computer memory. The form sent can be 
machine-dependent, to be defined on an as needed basis. Unless 
otherwise defined, each byte represents one memory byte. 

TRANSFER ADDRESS (4) : B = The starting memory address of the image just loaded. 

Note: 

IMAGE DATA or LOAD ADDRESS and IMAGE DATA may be omitted. Valid mes- 
sage lengths are 6 (LOAD ADDRESS and IMAGE DATA omitted), 10 (IMAGE 
DATA omitted), or greater than 10. IMAGE DATA is present only when loading a 
Secondary Loader. 

5.1.5 Memory Load 

The Memory Load message consists of: 



CODE 


LOAD 


LOAD 


IMAGE 


NUMBER 


ADDRESS 


DATA 



Figure 9: Memory Load message format 

Where: 

CODE (1 ) : B = The number 2. 

LOAD NUMBER (1) : B = As described for Memory Load with Transfer Address (see Section 
5.1.4). 

LOAD ADDRESS (4) : B = As described for Memory Load with Transfer Address. 
IMAGE DATA (*) : = As described for Memory Load with Transfer Address. 

Note: 

IMAGE DATA may be omitted. Valid message lengths may be 6 (IMAGE DATA 
omitted), or greater than 6. Messages without IMAGE DATA cause nothing to be 
loaded; however, the LOAD NUMBER value is still incremented for the next 
load. 



5.1.6 Parameter Load with Transfer Address 



The Parameter Load with Transfer Address message consists of: 



5.1.6: Parameter Load with Transfer Address 
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CODE 


LOAD 


PARAMETERS 


END 


TRANSFER 


NUMBER 


MARK 


ADDRESS 



Figure 10: Parameter Load with Transfer Address message format 



Where: 

CODE (1 ) : B = The number 20. 

LOAD NUMBER (1) : B = As described for the Memory Load with Transfer Address message 
(Section 5.1.4). 

PARAMETERS (*) : = Zero or more parameter entries. 

A parameter entry consists of: 



PARAMETER 


PARAMETER 


PARAMETER 


TYPE 


LENGTH 


VALUE 



Figure 1 1 : Parameter Load message Parameter field format 

Where: 

PARAMETER TYPE (1 ) : B = A type code for the parameter information. The values are: 

Value Parameter 

1 PHASE IV CLIENT NAME 

2 PHASE IV CLIENT ADDRESS 

3 PHASE IV HOST NAME 

4 PHASE IV HOST ADDRESS 

5 V3 FORMAT HOST SYSTEM TIME 

6 HOST SYSTEM TIME 

PARAMETER LENGTH (1) : B = The number of bytes in the PARAMETER VALUE field. 

PARAMETER VALUE (J-255) : = A value according to PARAMETER TYPE and 
PARAMETER LENGTH. Refer to Appendix G.5 for more detail 
on parameters 1-5. 

Where: 

PHASE IV CLIENT NAME (J-16) : A = ASCII system name target system is to 
use for itself. 

PHASE IV CLIENT ADDRESS (J-2) : B = Binary system address target system is 
to use for itself. 

PHASE IV HOST NAME (J-16) : A = ASCII system name of host assigned to 
system (for example, host for task loading of core only 
systems). 

PHASE IV HOST ADDRESS (J-2) : B = Binary system address of host. 

V3 FORMAT HOST SYSTEM TIME (10) : B = Segmented binary system time of 
host, consisting of: 

CENTURY YEAR MONTH DAY HOUR MINUTE 
SECOND 100TH TDFH TDFM 



where: 
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CENTURY (1) : B = 

YEAR (1) :B = 
MONTH (1) : B = 
DAY (1) : B = 
HOUR(1) :B = 
MINUTE (1) :B = 
SECOND (1) : B = 
100TH (1) : B = 
TDFH (1) : B = 
TDFM (1) : B = 



the century base for reckoning the absolute 
year. Value is a positive integer (0 through 
+ 127). 

the year of the base century. Value is in the 
range through 99. 

the month of the year, starting with January = 
1. Value is in the range 1 through 12. 

the day of the month. Value is in the range 1 
through 3 1 . 

the hour of the day. Value is in the range 
through 23. 

the minute of the hour. Value is in the range 
through 59. 

the second of the minute. Value is in the range 
through 59. 

the number of hundredths of a second. Value is 
in the range through 99. 

the hours portion of the Time Differential 
Factor. Value is in the range -12 through +13. 

the minutes portion of the Time Differential 
Factor. Value is in the range -59 through 59. 
The sign of this value must be the same as the 
sign of the TDFH value. 

HOST SYSTEM TIME (16) : B = The host system time, encoded in Binary 
Absolute Time format. 

END MARK (1 ) : B = The number 0. 

TRANSFER ADDRESS (4) : B = As described for the Memory Load with Transfer Address 
message (Section 5.1.4). 

5.2 Upline Dump messages 

The messages described in this section relate to the MOP Load/Dump components, for the 
Upline Dump service. On LANs, they are sent using the Load/Dump Protocol ID (08-00-2B- 
60-01). 

5.2.1 Request Dump Service 

The Request Dump Service message consists of: 



CODE 


DEVICE 


FORMAT 


MEMORY 


BITS 


OTHER 


TYPE 


VERSION 


SIZE 


INFO 



Figure 12: Request Dump Service message format 

Where: 



CODE (1) : B = 
DEVICE TYPE (1) 



The number 12. 
B = As described for the Request Program message. 



5.2.2: Request Memory Dump 
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FORMAT VERSION (1) : B = As described for the Request Program message (Section 5.1.1). 

MEMORY SIZE (4) : B = The size of physical machine memory. Units are as described for 
COUNT in the Request Memory Dump message (Section 5.2.2). 

BITS (1 ) : B = The number 2. Present for compatibility only; ignore on receipt. 

OTHER INFO (*) : = Further information to identify the requesting system. Definition is as 
described for the Remote Console System ID message (Section 5.5.3). 
The only valid INFO TYPE is DATA LINK BUFFER SIZE (401). 

Implementations are strongly encouraged to supply this field, since the 
dump server will otherwise assume a buffer size of 262, resulting in 
much reduced performance. 



5.2.2 Request Memory Dump 



The Request Memory Dump message consists of: 



CODE 



MEMORY 
ADDRESS 



COUNT 



Figure 13: Request Memory Dump message format 



Where: 



CODE (1 ) : B = The number 4. 

MEMORY ADDRESS (4) : B = The starting physical memory address for the dump. 

COUNT (2) : B = The number of locations to dump. The meaning of the count can be 

machine-dependent, to be defined on an as needed basis. Unless 
otherwise defined, the count is in bytes. 

Note: 

This request results in a single Memory Dump Data message. A dump should 
not be requested for more data than can be reliably sent in a single reply on the 
link used. The maximum data link message length limits the maximum length 
for a given link. 



5.2.3 Memory Dump Data 



The Memory Dump Data message consists of: 



CODE 


MEMORY 


IMAGE 


ADDRESS 


DATA 



Where: 
CODE (1) : B = 



Figure 14: Memory Dump Data message format 



The number 14. 



MEMORY ADDRESS (4) : B = As described for the Request Memory Dump message (Section 
5.2.2). 
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IMAGE DATA (*) : = 



As described for the Memory Load with Transfer Address message 
(Section 5.1.4). The length of this field must not exceed the COUNT 
specified in the Request Memory Dump message. Note that the field 
may be shorter (and may be null). 



5.2.4 Dump Complete 



The Dump Complete message consists of: 



CODE 



Figure 15: Dump Complete message format 



Where: 
CODE(1):B = 



The number 1 . 

5.3 Point to Point Loop Test messages 

The messages shown in this section are used by the MOP Loop components. They apply only 
to Loop operations on point to point data links. 

5.3.1 Loop Data Message for point to point links 

The Loop Data message for point to point links consists of: 



CODE 



RECEIPT 



DATA 



Figure 16: Loop Data message format for point to point links 

Where: 

CODE (1 ) : B = The number 24. 

RECEIPT (2) : B = The receipt number for the loop request. 
DATA (*) : B = The data to be looped back. 

5.3.2 Looped Data Message for point to point links 

The Looped Data message for point to point links consists of: 



CODE 



RECEIPT 



DATA 



Figure 17: Looped Data message format for point to point links 



Where: 



5.4: LAN Loop Test messages 
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CODE (1 ) : B = The number 26. 

RECEIPT (2) : B = The receipt number from the Loop Data message. 
DATA (*) : B = The data from the Loop Data message. 

5.4 LAN Loop Test messages 

The messages shown in this section are used by the MOP Loop components. They apply only 
to Loop operations on LAN data links. The Protocol ID used is the Loopback Protocol ID (08- 
00-2B-90-00). 

5.4.1 Forward Data message for LANs 

The Forward Data message for LAN data links consists of: 



SKIP 
COUNT 


skipped 


CODE 


ADDRESS 


DATA 



Figure 18: Forward Data message format for LAN links 



Where: 

SKIP COUNT (2) : B = The number of bytes to skip over preceding the CODE field. 
CODE (2) : B = The number 2. 

ADDRESS (6) : B = The address to which to forward the message. 

DATA (*) : B = The data to be interpreted by the station specified by the ADDRESS 

field. 

5.4.2 Looped Data message for LANs 

The Looped Data message (Reply message) for LAN data links consists of: 



SKIP 
COUNT 


skipped 


CODE 


RECEIPT 


DATA 



Figure 19: Looped Data message format for LAN links 



Where: 

SKIP COUNT (2) : B = The number of bytes to skip over preceding the CODE field. 

CODE (2) : B = The number 1. 

RECEIPT (2) : B = The receipt number. 

DATA (*) : B = The loop test data supplied by the Loop Requester. 

5.5 Console messages 

The messages described in this section relate to the MOP Console components. On LANs, 
they are sent using the Console Protocol ID (08-00-2B-60-02). Note that the Boot message is 
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in the category of Console messages, even though it is often used in conjunction with a downline 
load operation. 



5.5.1 Boot 



The Boot message consists of: 



CODE 



VERIFICATION 



PROCESSOR 



CONTROL 



Where: 



DEVICE 



SYSTEM J SCRIPT 
SOFTWARE ID I SOFTWARE ID 



Figure 20: Boot message format 



CODE (1) : B = 



The number 6. 



VERIFICATION (8) : B = A verification code that must match before the receiving system can 
honor the request. Note that there is no wild card value (the value 
%x0000000000000000 is used as a default, but has no other special 
significance). 

PROCESSOR (1) : B = As described for the Request Program message (Section 5.1.1). 

Note: 

The intent of this field is to specify which processor is to be booted. The state of 
the other processor, if any, shall not be disturbed in the process. This allows a 
host to boot one component without in the process forcing a complete reinitiali- 
zation of other components. 



CONTROL (1) :BM = 



Instructions to the system as to what device to use for the operation. 
Values are: 



Bit 



1 



Meaning 

Boot server 

Boot device 



Value 


1 


1 



Meaning 

System default 
Requesting system 
System default 
Specified device 



Note: 

Settings "Requesting system" (bit 0=1) and "Specified device" (bit 1 = 1) are 
mutually exclusive. 



DEVICE ID (C-17) : = The device to use. Present only if CONTROL<Boot-device> = Specified 
Device. Interpretation is specific to the receiving system. 

SYSTEM SOFTWARE ID (C-128) : = The System software the system is to load (i.e., the value to 
send in the Software ID field of the Request Program message that 
requests Program Type = System). Software identification consists of: 



5.5.2: Request ID 
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FORM 



ID 



Where: 

FORM (1) : B = 



ID(J-127) :A = 



Figure 21: Software ID field format 



The general type of software. Values are: 



Value 



>0 
-1 
-2 



Meaning 

No software id 
The length of the ID field 
Standard operating system 
Maintenance system 



A specific software ID. Present only if FORM > 0. The 
interpretation of this ID is specific to the receiving system. 

The ID string is required to consist only of the letters A 
through Z (hex values 41 through 5 A), digits to 9 (hex values 
30 through 39), and underscore (hex value 5F). In addition, 
Software IDs assigned by Digital must contain one $ sign (hex 
24) preceded by the Facility name for the product. Software 
IDs assigned by customers shall not contain a $ sign. A Load 
Host receiving a Request Program message with a Software ID 
field that does not meet this requirement shall ignore the 
message. 

As an example, the Software ID string can be interpreted as a 
filename, with the device name and directory supplied by the 
implementation or host installation. The facility prefix 
(terminated by the $ sign) used in Digital-defined Software IDs 
could be used to identify a subdirectory. For example, the 
following mapping could be done: 



FAC$XYZ 
XYZ 



/sys/mop/images/digital/fac/xyz 
/sys/mop/images/other/xyz 



SCRIPT SOFTWARE ID (C-128) : = The Script software the system is to load (i.e., the value to 
send in the Software ID field of the Request Program message that 
requests Program Type = CMIP Script). The format is the same as that 
of the System Software ID field, except that Form = -2 ("Maintenance 
system") is not used. 

5.5.2 Request ID 

The Request ID message consists of: 



CODE 



RESERVED 



RECEIPT 



Figure 22: Request ID message format 



Where: 
CODE (1) : B = 



The number 5. 
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RESERVED (1) : = 
RECEIPT (2) : B = 



A one byte field reserved to Digital for future use. Send 0; ignore on 
receipt. 

A receipt number to identify the request. The value is reserved for 
unsolicited System ID messages (periodically transmission of System 
ID, as required by the Auto-configuration). 



5.5.3 System ID 

The System ID message consists of: 



CODE 


RESERVED 


RECEIPT 


OTHER 
INFO 



Where: 
CODE(1):B = 
RESERVED (1) : ; 

RECEIPT (2) : B = 

OTHER INFO (*) : 



PAD 



Figure 23: System ID message format 



The number 7. 

A one byte field reserved to Digital for future use. Send 0; ignore on 
receipt. 

A receipt number to identify the request. The value is used to 
indicate an unsolicited System ID message. 

Further information to describe the system. Consists of zero or more 
entries in any order. Each entry consists of: 



INFO 


INFO 


INFO 


TYPE 


LENGTH 


VALUE 



Figure 24: System ID message Info field format 



Where: 

INFO TYPE (2) : B = 



Value 
1 

2 
3 
4 
5 
6 



Is the type of information. When processing the information 
elements of this message, implementations shall ignore any 
that have an unrecognized value in the INFO TYPE field. Such 
fields are processed by skipping the field (using the INFO 
LENGTH) and continuing processing with the next field, if any. 
The fields shown as "xxx Related" (101-199, 201-299, 402^199) 
are qualified by the field they relate to. For example, if field 
type 100 has the value 37 (DELQA), then the meanings of field 
types 101-199 (if any) is specific to the DELQA, and the code 
assignments are found in the specification for that device. The 
values are: 

Information 



MAINTENANCE VERSION 
FUNCTIONS 
CONSOLE USER 
RESERVATION TIMER 
CONSOLE COMMAND SIZE 
CONSOLE RESPONSE SIZE 



5.5.3: System ID 
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7 




HARDWARE ADDRESS 


8 




reserved 


9 


*** 


NODE ID 


10 




SYSTEM TIME 


11 


*** 


NODE NAME PART 1 


12 


*** 


NODE NAME PART 2 


13 


§ 


STATION ID 


100 


* 


COMMUNICATION DEVICE 


101-199 




COMMUNICATION DEVICE Related 


200 




SOFTWARE ID 


201-299 




SOFTWARE ID Related 


400 


n 


DATA LINK 


401 




DATA LINK BUFFER SIZE 


402-499 




DATA LINK Related 



* Required field (System ID message only). 

** Required field if console carrier available. (FUNCTIONS bit 5). 

*** Required field when the system is not in Primitive state. Optional in 

Primitive state. 
§ Required field if Data Link is FDDI. 

n Required field if Data Link is other than CSMA/CD. Recommended field if 
Data Link is CSMA/CD. 

INFO LENGTH (1) : B = The number of bytes in the INFO VALUE field. This value shall 
be large enough to accommodate the value, i.e., at least as 
large as the size shown below for each value. Note that it is 
possible for the field to be larger than the minimum required. 

INFO VALUE : = The value according to INFO TYPE and INFO LENGTH. 

Where: 

MAINTENANCE VERSION (3) : B = The MOP version number. The bytes, in 
order from low to high, are version, ECO, and user 
ECO. The values are 4, and 0. 

FUNCTIONS (2) : BM = The maintenance functions currently available through 
this link. The bit meanings are: 

Bit Function 

Loop Server (required function) 

1 Dump Client 

2 Primary loader Client (can only load 
secondary loader) 

3 Multi-block loader Client (can load 
tertiary loader, management data, CMIP 
script, or system) 

4 Boot (console server) 

5 Console carrier Server 

6 Data link counters (required function 1 , 
console server) 

7 Console carrier reserved 

Note that bit 7 (Console Carrier Reserved) indicates the current state of the con- 
sole reservation, while all other bits indicate whether the corresponding func- 
tion is supported or not. 



Note: for the FDDI data link this function is required, and should be reported, only when sending System ID mes- 
sages in MOP V4 format. When sending in V3 format, this bit should be zero. Refer to Appendix G for more 
detail. 
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Messages 



CONSOLE USER (6) : B = System address of the system that has the console 
reserved. Not present if not applicable. Must be 
present if console carrier is available, i.e., FUNCTION 
bit 5 is ON. Not valid if the console carrier is not 
reserved, i.e., FUNCTION bit 7 is OFF. 

RESERVATION TIMER (2) : B = The maximum value, in seconds, of the timer 
used to clear unused console reservations. Not present 
if not applicable. Must be present if console carrier is 
available, i.e., FUNCTION bit 5 is ON. 

CONSOLE COMMAND SIZE (2) : B = The maximum size of the console command 
buffer. Not present if not applicable. Must be present 
if console carrier is available, i.e., FUNCTION bit 5 is 
ON. 

CONSOLE RESPONSE SIZE (2) : B = The maximum size of the console response 
buffer. Not present if not applicable. Must be present 
if console carrier is available, i.e., FUNCTION bit 5 is 
ON. 

HARDWARE ADDRESS (6) : B = The default data link address for the circuit on 
which this message is sent, i.e., the value in the MAC 
Address ROM of this circuit. 

NODE ID (6) : B = The Node ID of this system (i.e., the value of the Node 

entity status attribute NodelD). Required when the 
system is not in primitive state. 

SYSTEM TIME (16) : B = The system time, represented as a Binary Absolute 
Time according to the Digital Standard for 
Representation of Time. 

NODE NAME PART 1 (J-255) : = The Node Name of this node, encoded as a 
Name Service FullName. If the node name has not 
been set yet, or the ability to set the node name is not 
supported in this node, this field may be sent as null, or 
may be omitted. If the complete node name is longer 
than 255 bytes, the first 255 bytes are sent in this field 
and the remainder is sent in NODE NAME PART 2. 

NODE NAME PART 2 (J-255) : = The portion of the Node Name of this node, 
encoded as a Name Service FullName, beyond the first 
255 bytes. If the Node Name does not exceed 255 bytes, 
or the node does not support the ability to set a node 
name, this argument may be omitted or may be sent as 
null. 

STATION ID (8) : B = The Station ID of this system FDDI Station (i.e., the 
value of the FDDI Data Link entity status attribute 
Station ID for this circuit). Required on FDDI circuits 
in all node states. Not present for circuits other than 
FDDI. 

COMMUNICATION DEVICE (1) : B = The hardware device type of the link being 
used. Values are in Appendix A. 1 . 

COMMUNICATION DEVICE RELATED : = Information specific to the particular 
COMMUNICATION DEVICE. Not present if not 
applicable. Length and encoding vary according to the 
specific definition of these fields for a given 
COMMUNICATION DEVICE value. 



5.5.4: Request Counters 
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SOFTWARE ID (C-128) : = The identification of the software the system is 
supposed to be running. The format is the same as 
defined for the Boot message (Section 5.5.1). 

SOFTWARE ID RELATED : = Information specific to the particular SOFTWARE 
ID. Not present if not applicable. Interpretation is 
specific to the receiving system (e.g., file specification, 
which may vary depending on the type of file server). 
Length and encoding vary according to the specific 
definition of these fields for a given SOFTWARE ID 
value. 

DATA LINK (1) : B = The type of data link protocol on the link being used. 
Values are in Appendix A. 2. 

DATA LINK BUFFER SIZE (2) : B = The size of the data link buffer. Not present 
if not applicable. The default value is 262. This 
specifies the length of the data passed from MOP to the 
data link layer; it includes the MOP header but not the 
data link envelope. A server that does not recognize 
this field may ignore this field, so that all requesters 
must support 262 byte messages. In both Ethernet and 
802 (LLC SNAP) format, it includes only the length of 
the LLC Data, i.e., the MOP protocol header and data, 
but not any part of the data link envelope. 

Note: the use of a buffer size of 262 will result in 
drastic loss of performance. The fact that 262 is the 
default used by (old) servers that do not recognize the 
Data Link Buffer Size field does not mean that any 
server may choose to ignore this information. Instead, 
servers are expected to use the value supplied by the 
client. Furthermore, all clients should use the largest 
buffer size allowed for the data link in question 
whenever possible. 

DATA LINK RELATED : = Information specific to the particular DATA LINK. Not 

present if not applicable. Length and encoding vary 
according to the specific definition of these fields for a 
given DATA LINK value. 

PAD (1— 3) : B = Possible padding. Conforming implementation shall not pad the 

System ID message. For compatibility with certain existing 
implementations, stations receiving System ID messages shall accept 
up to 3 bytes of padding with at the end of the message. 

5.5.4 Request Counters 

The Request Counters message consists of: 



CODE 



RECEIPT 



Figure 25: Request Counters message format 

Where: 

CODE (1 ) : B = The number 9. 
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Messages 



RECEIPT (2) : B = A receipt number to identify the request. 
5.5.5 Counters (CSMA/CD only) 

The Counters message in the case of the CSMA/CD data link consists of: 



CODE 



RECEIPT 



COUNTER 
BLOCK 



Where: 

CODE(1):B = 
RECEIPT (2) : B = 



Figure 26: Counters message format for CSMA/CD link 
The number 1 1 . 

A receipt number to identify the request. 



COUNTER BLOCK (*) : = A block of counters as defined for the CSMA/CD data link (see 
Appendix B.4). 

5.5.6 Counters (other than CSMA/CD) 

The Counters message for data links other than CSMA/CD consists of: 



CODE 


DATA 
LINK 


RECEIPT 


COUNTER 
BLOCK 



Figure 27: Counters message format for links other than CSMA/CD 

Where: 

CODE (1) : B = The number 21. 

DATA LINK (1) : B = The type of data link protocol on the link being used. Values are in 
Appendix A. 2. 



RECEIPT (2) : B = 



A receipt number to identify the request. 



COUNTER BLOCK (*) : = A block of counters as defined for the particular data link (see 
Appendix B). 

5.5.7 Reserve Console 

The Reserve Console message consists of: 



CODE 



VERIFICATION 



Figure 28: Reserve Console message format 



Where: 
CODE(1):B = 



The number 13. 



5.5.8: Console Command and Poll 
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VERIFICATION (8) : B = A verification code that must match before the receiving system can 
honor the request. 

5.5.8 Console Command and Poll 

This message is issued by the Console Requester in the command system and is received by 
the Console Server in the target system. The Console Command and Poll message consists of: 



CODE 


CONTROL 


COMMAND 


FLAGS 


DATA 



Figure 29: Console Command and Poll message format 

Where: 

CODE (1 ) : B = The number 17. 

CONTROL FLAGS (1 ) : BM = The control flags indicate the state of the console carrier message 
streams. They insure that messages are not lost. 

Bit Function 

Message Number — indicates the current message number. 
This is a one bit sequence number of the current Console 
Requester command message. 

1 Command Break Flag — indicates if the (possibly null) 
command data is to be preceded by a break condition in the 
serial byte stream. This may take on the value of zero, 
meaning no break, or one, meaning there is a break. 

COMMAND DATA (*) : = This is a (possibly null) sequence of bytes to be provided as input to the 
receiving system's higher level user of the Console Server. 

5.5.9 Console Response and Acknowledge 

This message is issued by the Console Server in the target system in response to the receipt 
of a Console Command and Poll message from the Console Requester in the command system. 
The Console Response and Acknowledge message consists of: 





CONTROL 


RESPONSE 


CODE 


FLAGS 


DATA 



Figure 30: Console Response message format 

Where: 

CODE (1) : B = The number 19. 

CONTROL FLAGS (1 ) : BM = The control flags indicate the state of the console carrier message 
streams. They insure that messages are not lost. 

Bit Function 
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Messages 



Message Number — indicates the current message number. 
This is a one bit sequence number of the current command 
message being acknowledged. 

1 Command Data Lost Flag — indicates if some console 
command data was lost. This may take on the value of zero, 
meaning acceptance of the command data, or one, meaning 
that some command data was lost. 

Note that the requester should not resend the command 
data, since part of the data may have been accepted. In 
that case, resending will produce unpredictable results. 
Instead, the error should simply be reported to the user. 

2 Response Data Lost Flag — indicates if remote console 
response data was lost due to data overrun. This may take 
on the value of zero, meaning no detection of lost data, or 
one, meaning there was lost data. 

RESPONSE DATA (*) : = This is a (possibly null) sequence of bytes to be provided as input to the 
receiving system's higher level user of the Console Requester. 

5.5.10 Release Console 

The Release Console message consists of: 



CODE 



Where: 
CODE (1) : B = 



Figure 3 1 : Release Console message format 
The number 15. 
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Appendix A 



Predefined Values 



This appendix contains the predefined values for various maintenance operation parameters. 
These values are referenced in the interfaces and in the message definitions. Each parameter 
has a description to be used in the interface calls and an actual value to be used in protocol 
messages. 

The values shown here reflect the state of the MOP Registry as of the publication date of this 
specification. New values are defined on an as needed basis. Any values not shown are re- 
served for use by Digital. 

A.l Communication Devices 



Value Name Device 



1 


UNA 


DEUNA UNIBUS CSMA/CD communication link 


2 


DU 


DU1 1-DA synchronous line interface 


3 


CNA 


DECNA Professional CSMA/CD communication link 


4 


DL 


DL1 1-C, -E or -WA asynchronous line interface 


5 


QNA 


DEQNA Q-bus CSMA/CD communication link 


7 


CI 


Computer Interconnect interface 


8 


DA 


DAI 1-B or -AL UNIBUS link 


9 


PCL 


PCL1 1-B UNIBUS multiple CPU link 


10 


DUP 


DUP 11 -DA synchronous line interface 


11 


LUA 


DELUA UNIBUS CSMA/CD communication link 


12 


DMC 


DMC 11 -DA/ AR, -FA/AR, -MA/AL or -MD/AL synchronous link 


13 


LNA 


MicroServer Lance CSMA/CD communication link 


14 


DN 


DN1 1-B A or -AA automatic calling unit 


16 


DLV 


DLV1 1-E, -F, -J, MXV1 1-A or -B asynchronous line interface 


17 


LCS 


LANCE/DECserverlOO CSMA/CD communication link 


18 


DMP 


DMP 11 UNIBUS multipoint synchronous link 


20 


DTE 


DTE20 PDP-1 1 to KL10 interface 


21 


DBT 


DEBET CSMA/CD communication link 


22 


DV 


DV11-AA/BA UNIBUS synchronous line multiplexer 


23 


BNA 


DEB NT BI CSMA/CD communication link 


24 


DZ 


DZ1 1-A, -B, -C, or -D UNIBUS asynchronous line multiplexer 


25 


LPC 


VAXmate (LANCE) CSMA/CD communication link 


26 


DSV 


DSV11 Q-bus synchronous link 


27 


CEC 


3Com 3C501, IBM-PC CSMA/CD adapter 


28 


KDP 


KMC1 1/DUP1 1-DA synchronous line multiplexer 


29 


IEC 


Micom/Interlan 5010, IBM-PC CSMA/CD adapter 



120 Predefined Values 



30 


KDZ 


KMC1 1/DZ1 1-A, -B, -C, or -D asynchronous line multiplexer 


31 


LQA 


DELQA CSMA/CD communication link, alternate assignment. See note 






below. 


33 


DS2 


LANCE/DECserver 200 CSMA/CD communication link 


34 


DMV 


DMV 11 Q-bus synchronous link 


35 


DS5 


DECserver 500 CSMA/CD communication link 


36 


DPV 


DPV1 1 Q-bus synchronous line interface 


37 


LQA 


DELQA CSMA/CD communication link. See note below 


38 


DMF 


DMF-32 UNIBUS synchronous line unit 


39 


SVA 


DESVA Microvax-2000, 3100, 3300 CSMA/CD communication link 


40 


DMR 


DMR1 1-AA, -AB, -AC, or -AE UNIBUS interprocessor link 


41 


MUX 


MUXServer 100 CSMA/CD communication link 


42 


KMY 


KMS11-PX UNIBUS synchronous line interface with X.25 level 2 






microcode 


43 


DEP 


DEPCA PCSG/IBM-PC CSMA/CD communication link 


44 


KMX 


KMS1 1-BD/BE UNIBUS synchronous line interface with X.25 level 2 






microcode 


45 


LTM 


LTM (911) Ethernet monitor 


46 


DMB 


DMB-32 BI synchronous line multiplexer 


47 


DES 


DESNC Ethernet Encryption Module 


48 


KCP 


KCP Professional synchronous/asynchronous comm port 


49 


MX3 


MUXServer 300 CSMA/CD communication link 


50 


SYN 


MicroServer Synchronous line interface 


52 


DSB 


DSB32 BI Synchronous Line Interface 


53 


BAM 


DEB AM LANBridge-200 Data Link 


54 


DST 


DST-32 TEAMmate Synchronous Line Interface (DEC423) 


58 


3C2 


3COM Etherlink II (part number 3C503) 


59 


3CM 


3COM Etherlink/MC (part number 3C523) 


60 


DS3 


DECServer 300 CSMA/CD communication link 


61 


MF2 


Micro VAX 3300 CSMA/CD communication link 


63 


VIT 


Vitalink TransLAN III/IV (NP3A) Bridge 


64 


VT5 


Vitalink TransLAN 350 (NPC25) Bridge, TransPATH 350 BRouter 


65 


BNI 


DEBNI BI CSMA/CD communication link 


66 


MNA 


DEMNA XMI CSMA/CD communication link 


67 


PMX 


DECstation-3100 CSMA/CD communication link 


72 


DP2 


DECserver-250 (parallel printer server) CSMA/CD communication link 


73 


ISA 


Pele SGEC-based CSMA/CD communication link 


74 


DIV 


DIV-32 Q-bus ISDN (2B+D) adapter 


75 


QTA 


DEQTA (DELQA- YM) CSMA/CD comm link 


76 


B15 


LANbridge-150 CSMA/CD comm link 


86 


DR2 


DECrouter-250 CSMA/CD comm link 


87 


sec 


DECrouter-250 DUSCC serial comm link (DDCMP or HDLC) 


90 


FBN 


DECbridge-5xx CSMA/CD comm link 


91 


FEB 


DECbridge-5xx, -6xx FDDI comm link 


92 


FCN 


DECconcentrator-500 wiring concentrator FDDI comm link 


93 


MFA 


DEMFA XMI — FDDI comm link 


94 


MXE 


MIPS workstation family CSMA/CD comm links 






(3MAX/KN02 system board; PMAD option board) 


101 


DSF 


DSF-32 2 line synchronous comm link for Cirrus 


104 


KFE 


VAXft-3000 KFE52 CSMA/CD comm link 


105 


RT3 


rtVAX-300 SGEC-based CSMA/CD comm link 


112 


L20 


LPS20 print server CSMA/CD comm link 


114 


DWT 


VT-1000 DECwindows terminal 


115 


WGB 


DEWGB Work Group Bridge CSMA/CD comm link 


118 


MNE 


3MIN (KN02-BA) integral CSMA/CD comm link 


119 


FZA 


DEFZA TurboChannel FDDI comm link 


120 


90L 


DS90L terminal server CSMA/CD comm link 


135 


TRN 


DEQRA token ring (802.5) comm link 



A. 2: Data Links 
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139 
140 
141 
142 
145 



ISE 
1ST 
ISH 
ISF 
FB3 



Network Integration Server 600 (Hastings) CSMA/CD line card 
Network Integration Server 600 (Hastings) Tl sync line card 
Network Integration Server 600 (Hastings) 64 kb HDLC line card 
Network Integration Server 600 (Hastings) FDDI line card 
DECbridge-6xx CSMA/CD (3 port) comm link 



Note: 



Note on the assignment for the DELQA: the primary assignment is 37. Device 
code 3 1 is used in early DELQA devices when used on PDP- 1 1 systems, in the 
"Request Program" message only. Later revisions of the DELQA use code 37 
throughout. Software shall treat codes 3 1 and 37 as equivalent. 

Note on the assignment for MicroVAX 3300 integral CSMA/CD comm link: 
there is a specific assignment for this device (61, mnemonic "MF2"). This code is 
used by the boot ROMs. Operating system drivers treat it as equivalent to the 
MicroVAX 2000 integral CSMA/CD comm link and use the code assigned to that 
device (39, "SVA"). 



A.2 Data Links 



The data link type values are: 



Value 


Meaning 


1 


CSMA-CD 


2 


DDCMP 


3 


LAPB (frame level of X.25) 


4 


HDLC 


5 


FDDI 


6 


Token-passing Ring (IEEE 802.5) 


7-10 


Reserved 


11 


Token-passing Bus (IEEE 802.4) 


12 


Z-LAN 4000: Zenith 4 Megabit/second broadband CSMA/CD LAN 



Note that these codes are not the same as the "Circuit Type" codes used in the management 
interface, which are defined in Section 3.4. To simplify the mapping between these two encod- 
ings, new values for Circuit Type and Data Link Type will be assigned such that the following 
algorithm applies: 



IF DataLinkType s 10 

THEN CircuitType := LookupTable[DataLinkType] 
ELSE CircuitType := DataLinkType - 5 
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Appendix B 



Data Link Specific Information 



This appendix contains information necessary to relate specific data link types to the main- 
tenance operations. 

B.l DDCMP 

The Digital Data Communication Message Protocol (DDCMP) Data Link is a point-to-point 
link and allows exclusive maintenance operation in its maintenance mode. It does not require 
message padding. 

B.2 LAPB 

The LAPB Data Link is the frame level of X.25. It is a point-to-point link and allows exclu- 
sive maintenance operation for loopback only. It does not require message padding. 

B.3 HDLC 

The HDLC Data Link is a point to point link. It supports concurrent maintenance operation 
(MOP protocol messages are carried via the Unsequenced Information service of HDLC). It 
does not require message padding. 

The HDLC protocol ID is 01—01; it is used for all MOP protocol messages (unlike the LAN 
case where multiple protocol IDs or protocol types are used). 

B.4 CSMA/CD 

The CSMA/CD Data Link is the Digital Equipment Corporation implementation of the inter- 
company Ethernet Data Link and the IEEE 802.3 Data Link. It allows concurrent maintenance 
operation and is a LAN (multi-access) data link. As such it has specific protocol types and 
multicast addresses that go with it. It requires message padding when Ethernet frame format 
is used, except for the Loop protocol. 

Refer to the the LAN Node Product Architecture Specification and the DNA CSMA/CD Data 
Link Architectural Specification for specific functions and requirements. 

The protocol types are: 
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Data Link Specific Information 



Value Protocol 

90-00 Loopback 

60-01 Dump/Load 

60-02 Remote Console 



The IEEE 802 SNAP SAP Protocol Identification are : 



Value 

08-00-2B-90-00 
08-00-2B-60-01 
08-00-2B-60-02 



Protocol ID 

Loopback 
Dump/Load 
Remote Console 



The multicast addresses are: 



Address Group 
CF-00-00-00-00-00 Loopback assistance 
AB-00-00-0 1-00-00 Dump/Load assistance 
AB-00-00-02-00-00 Remote Console 



CSMA/CD data link counters can be read through the Remote Console. The counters are 
defined in the DNA CSMA/CD Data Link specification. The counters are a fixed format block 
with each value as indicated below. All fields must be included in the order specified. If a 
counter is not implemented, the corresponding field is still included, with a value of zero. Note 
that MOP V3 omitted the last field (Collision detect check failure), and used counters of a differ- 
ent width. In V4, all counters are 64 bits (8 bytes) long. The "time since counter creation" 
value is a Binary Relative Time. Systems that request Data Link counters using MOP can use 
the length of the received counters block to distinguish the two versions. 



Note: 

Unlike the MOP V3 counter block, the "Time since counter creation" field is not 
in seconds. It is encoded as a Binary Relative Time according to the encoding 
rules specified in the Time Representation specification. 

Length Counter Value 

16 Time since counter creation 

8 Bytes received 

8 Bytes sent 

8 Frames received 

8 Frames sent 

8 Multicast bytes received 

8 Multicast frames received 

8 Frames sent, initially deferred 

8 Frames sent, single collision 

8 Frames sent, multiple collisions 

8 Send failure — Excessive collisions 

8 Send failure — Carrier check failed 

8 Send failure — Short circuit 

8 Send failure — Open circuit 

8 Send failure — Frame too long 

8 Send failure — Remote failure to defer 

8 Receive failure — Block check error 

8 Receive failure — Framing error 

8 Receive failure — Frame too long 

8 Unrecognized frame destination 

8 Data overrun 

8 System buffer unavailable 

8 User buffer unavailable 

8 Collision detect check failure 



B.5: FDDI 
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B.5 FDDI 

The FDDI Data Link is the Digital Equipment Corporation implementation of the ANSI 
standard FDDI (Fiber Distributed Data Interface) Data Link. It allows concurrent mainte- 
nance operation and is a LAN (multi-access) data link. It supports the IEEE 802.2 LLC service. 

Refer to the the LAN Node Product Architecture Specification and the DNA FDDI Data Link 
Architectural Specification for specific functions and requirements. 

The FDDI Data Link uses the same SNAP Protocol Identification and multicast address as- 
signments as the CSMA/CD Data Link. In addition, it also uses the same Protocol Type assign- 
ments for use with the Mapped Ethernet packet service of the FDDI Data Link architecture. 
(This service sends IEEE 802.2 SNAP format packets with Protocol ID values recognized by 
LAN Bridges. When such packets are forwarded onto CSMA/CD links, they are converted into 
Ethernet format. MOP uses this service to communicate with MOP V3 implementations on 
Ethernet links.) 

FDDI Data Link counters can be read through the Remote Console. The counters are de- 
fined in the DNA FDDI Data Link specification. The counters are a fixed format block with 
each value as indicated below. All fields must be included in the order specified. If a counter is 
not implemented, the corresponding field is still included, with a value of zero. This counter 
block is returned in the "Counters (other than CSMA/CD)" message (Section 5.5.6). Since that 
message did not exist in MOP V3, MOP will ignore requests for counters in V3 format. 

Length Counter Value 



16 


Time since counter creation 


8 


Octets received 


8 


Octets sent 


8 


Frames received 


8 


Frames sent 


8 


Multicast octets received 


8 


Multicast octets sent 


8 


Multicast frames received 


8 


Multicast frames sent 


8 


Transmit underruns 


8 


Transmit failures 


8 


Block check errors 


8 


Frame status errors 


8 


Frame alignment errors 


8 


Frames too long 


8 


Unrecognized individual frame destinations 


8 


Unrecognized multicast frame destinations 


8 


Receive data overruns 


8 


Link buffers unavailable 


8 


User port buffers unavailable 


8 


Frame count 


8 


Error count 


8 


Lost count 


8 


Ring initializations initiated 


8 


Ring initializations received 


8 


Duplicate address test failures 


8 


Duplicate tokens detected 


8 


Ring purge errors 


8 


Bridge strip errors 


8 


Traces initiated 


8 


Link selftest failures 



127 



Appendix C 



Implementation Specific Dump/Load 



Characteristics 



This appendix documents characteristics of PDP-1 1 dump/load programs existing as of the 
date of this specification. 

C.l Secondary Loader 

The secondary loader is sent as a single Memory Load with Transfer Address message as 
normally required. In addition to this requirement, it must be loaded and started at location 6. 
Current secondary loaders are between 400 and 600 bytes in length, depending upon the device 
type used. They use the stack address set up by the primary loader. For current loaders this 
will be between 17400(octal) and 17776(octal). The secondary loader assigns its buffer space 
below the stack. The secondary loader accepts Memory Load with and without Transfer Ad- 
dress messages. It is, therefore, capable of doing multi-block loads into absolute addresses 
without memory management. It requests a tertiary loader to be loaded. 

The DMP-1 1 and DMV-1 1 do not set up the stack pointer or Rl as described. For those de- 
vices, Rl contains the device unit number. 

C.2 Tertiary Loader 

The tertiary loader is loaded by the secondary in a multi-block load starting at location 
lOOOO(octal). It will run with memory management on if it exists on the system. The tertiary 
loader moves itself to the top of physical memory and assigns its stack and buffer space just 
below itself. It is, therefore, capable of multi-block loads from location up to its buffer ad- 
dress, usually the last 1-2K words of physical memory. It requests the operating system to be 
loaded. The current tertiary loaders do not specify any specific operating system. The choice of 
system to send is established by prior agreement or by command at the host system. 
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LAN Loop Test Examples 



The following examples address the application of the Loop Test functions. They are in- 
tended as examples of how a higher level process can use the facilities. They are intended nei- 
ther as a specification for how they must be used nor as an exhaustive test script. 

In the examples, no account is taken of the fact that the Loop Test functions make only one 
attempt to transmit a message. To increase the reliability of the tests, each interface function 
that fails due to a communication error should be retried enough times to lessen the probability 
that an intermittent error occurred. 



D.l Local Control Test Example 

In this case, a node finds itself unable to communicate with some other node that it believes 
is on the network and operational. The following test script can be used by the node to check 
out the problem. 

First, LoopDirect is invoked with remoteAddress set at the correct address of the specific re- 
mote node, the suspect node. This results in a simplest, two hop frame consisting of : 

1. a Forward Data message which specifies the testing node's address as the forwarding 
address, containing 

2. a Reply message. 

This frame is transmitted to the suspect node. If this test succeeds, the communication is 
possible and the problem may have been either intermittent, the remote node is down, or there 
is a problem with message length or data pattern. Different message lengths and/or data pat- 
terns could then be tried. 

If the above test, LoopDirect, results in a return indicating failure, next invoke LoopAs- 
sisted, using some other node as assistantAddress. This will construct a loop test datagram as 
follows: 

1. a Forward Data message which specifies the suspect node's address as the forwarding 
address, containing: 

2. a Forward Data message which specifies the assistant's node address as the forwarding 
address, containing: 
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3. a Forward Data message which specifies the testing node's address as the forwarding 
address, containing: 

4. a Reply message. 

This frame is transmitted to the assistant node. This four-part datagram obtains the full 
assistance of the loopback assistant. 

If no assistant address is known, invoke LoopDirect with no remoteAddress parameter to 
send a simple, two hop loop test datagram to the Loopback Assistance Multicast Address. Use 
the source address of any responding node as an assistant address. If no communication with 
the Loopback Multicast Assistance group is possible, then the last resort is to obtain a list of 
nodes on the network. The list can be obtained by either listening to the Remote Console 
Multicast Address for the Remote Console System ID messages or obtaining such information 
from the network manager. From the list of nodes, select a node for loopback assistant by re- 
peating the above procedure. If this fails then repeat the process with other nodes on the list. 
If this fails with all the nodes on the list, then either no one else is turned on or the local node is 
broken. 

If some loopback assistant node can communicate with the remote node but the local node 
cannot, the local node can then test for the direction in which communication does not work. 
The LoopAssisted function, using the assistant node that responded previously as the assistant, 
can be used to detect either transmit or receive problems. This is accomplished using various 
assistance level, transmit or receive or full, supported by the loopAssisted function. By repeat- 
ing the above test with different remote nodes, it can be determined whether the local node or 
the remote node is at fault, thus isolating the problem to a particular transmitter or receiver. 

When a node finds itself unable to communicate, it can report this in whatever high level 
way is available. An operator or control center can then respond by attempting to isolate and 
repair the problem. 

D.2 Remote Control Test Example 

When a control center receives a report that a node cannot communicate properly, it can use 
the Loop Test functions to investigate the problem. It can first diagnose its own ability to com- 
municate with the node. If this communication appears to work, the control center can simi- 
larly check its ability to communicate with the remote node that the reporting node could not 
reach. 

If the control center can communicate with both nodes, it can then use LoopAssisted, full as- 
sistance, with one of the nodes as assistant and the other as remote to see if they can communi- 
cate. Similarly it can use transmit and receive assistance to determine which direction is a 
problem. 

Similar checks using other nodes can be used to isolate the problem to a particular transmit- 
ter or receiver. 
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Load File Formats 



E.l CMIP Script File Format 

The MOP protocol specifies a way for downline loading initialization management directives 
in the form of a sequence of CMIP directive messages, called a CMIP Script. In order to allow 
initialization scripts to be manipulated on various nodes that may be different implementations 
than the load hosts, it is also necessary to specify the file format of initialization scripts. The 
following specification applies only to files used as MOP initialization scripts. Whether they 
can also be used in other ways, for example as scripts accepted by management directors, is be- 
yond the scope of this architecture specification. The CMIP Script file has the structure of an 
RMS sequential file with variable-length records. The records of the file correspond one-to-one 
with the CMIP Script messages sent in the protocol. In particular, the first record contains the 
CMIP version number as described in the DNA CMIP architecture specification, and subse- 
quent records contain the directive messages, one per record. The RMS FDL description of the 
record format is as follows: 

FILE 

ORGANIZATION sequential 

RECORD 

BLOCK_SPAN yes 

CARRIAGE_CONTROL none 

FORMAT variable 

SIZE 

In the file, each record is preceded by a 2 byte field specifying the byte count of the record. If 
the byte count is odd, a pad byte (null) follows the record, thereby aligning the byte count fields 
on even boundaries. Block boundaries are given no special processing. End of file is indicated 
by a 2 byte field of hex FFFF instead of the byte count, and the remainder of the block is null- 
filled. 

These files can be processed by RMS or directly by simple application code, and can be trans- 
ferred using the DAP protocol (using Block mode if necessary). 
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LAN Frame Formats 



Note: 

This appendix is not part of the specification and is not under the control of the 
DNA review process. It is included here for information only. 

The following diagrams illustrate examples of LAN frame formats for several of the LAN 
data links. Refer to the appropriate Data Link architecture specification for a detailed descrip- 
tion of the messages and fields. 
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Figure 32: NI Frame Formats 



Preamble: A sequence of encoded bits which the Physical Layer transmits before 

each frame to allow synchronization of clocks and other Physical Layer 
circuitry at the receivers. 

FC: Frame Control field defines the type of the frame and certain MAC and 

management specific information frame functions. 



DA: 



the Destination Data Link Address 
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SA: the Source Data Link Address 

Length: the number of octets of user data (optional for Ethernet format). It is 

applicable for CSMA/CD LAN only. 

Prot Type: the Protocol Type for Ethernet frames 

PID: the Protocol Identifier for 802.2 PDUs addressed to the SNAP SAP 

LLC: IEEE 802.2 Logical Link Control sublayer 

PDU: Protocol Data Unit 

SNAP: the 802. 1 Sub-Network Access Protocol 

DSAP: the LLC Destination Service Access Point Address 

SSAP: the LLC Source Service Access Point Address 

Ctl: the LLC PDU Control field. For connectionless service it is one of: 

UI: the Unnumbered Information type LLC PDU Control field 

XID: the Exchange Identification type LLC PDU Control field 

TEST: the Test type LLC PDU Control field 
Data: the MAC user data 

Info: the LLC SAP user data 

M_Inf: the 802 SNAP Protocol Identifier user data 

PAD: the padding octets (optional for Ethernet format) 

FCS: the Frame Check Sequence 

EFS: End-of-Frame Sequence. The EFS typically contains the Ending 

Delimiter (ED), to mark the end of the frame, and the Frame Status. 
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Compatibility with Previous Versions 



This appendix discusses what implementations of V4.0 of the MOP architecture need to do in 
order to communicate with implementations of earlier versions of the MOP architecture, specifi- 
cally V3.0.0 and V3.1.0. Refer to the MOP V3 architecture specification for more details about 
message formats and algorithms for that protocol version. 

G.l Support for the previous version of MOP 

In the Load Client and Dump Client components, support for MOP V3 is a product imple- 
mentation choice. General purpose products should include V3 support in the Load/Dump Cli- 
ents to ensure flexibility in the choice of Load/Dump Servers. Bounded (fixed function) prod- 
ucts for which it is acceptable to limit the choice of Load/Dump Servers to only those that 
support MOP V4 may omit the V3 support from the Load/Dump Clients. 

For all other functions, support for MOP V3 is required. 

Note, however, that certain functions of MOP V4 are not defined in MOP V3. These func- 
tions are of course exempt from the above requirement. The functions specific to MOP V4 are: 

• HDLC support 

• Response to the Read Counters request message on FDDI data links 

• CMIP Script down line load 

G.2 Ethernet and 802 frame formats 

On a CSMA/CD LAN, the data link allows the use of both 802 format and Ethernet format 
frames. MOP uses 802 format frames (using SNAP format LLC frames) in V4. MOP V3 used 
Ethernet format packets. 

Other LANs, such as FDDI, do not have the direct equivalent of "Ethernet" format; they only 
support IEEE 802.2 LLC. To support communication with nodes that use Ethernet message 
formats across LAN Bridges, there exists a packet format mapping that maps Ethernet packets 
(with 2 byte Protocol Types) into IEEE 802.2 packets (using SNAP, with 5 byte Protocol IDs). 
The data link layer architecture for these LANs describes this mapping in detail. In the service 
interface, the service provided is essentially identical to that of the CSMA/CD data link with its 
support of Ethernet format. Consequently, the rules about the use of Ethernet format on LANs 
apply to all LANs; in the case of LANs other than CSMA/CD the encapsulated Ethernet packet 
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service of the data link is used for this. In particular, where nodes are required to support MOP 
V3, this requirement applies to non-CSMA/CD LANs as well as to CSMA/CD, unless specifically 
stated otherwise. 

G.2.1 Response to received requests 

MOP V4 implementations listen for requests both in 802 (V4 format) and in Ethernet (V3 
format) frames. The response to the request is in the same frame format as the request. If the 
request was in an Ethernet format frame, it is interpreted and responded to according to the 
algorithms specified in the MOP V3 architecture specification (except as noted below). 

G.2.2 Initiation of requests 

MOP V4 implementations send requests both in 802 (V4 format) and in Ethernet (V3 format) 
frames. In the case of the Ethernet format request, the message is formatted according to the 
V3 architecture rules. The 802 format request is sent out first; if no response is received in the 
timeout period, the Ethernet format request is then sent. If that times out as well, the 802 for- 
mat request is sent again. Each iteration of 802 format, then Ethernet format frame counts as 
one retry. As an optimization, an implementation may send both formats at the same time. 
For some protocol exchanges (e.g., Loop) care must be taken not to confuse the replies; the re- 
ceipt number in the message can be used to do this. 

The algorithm for the Boot message is slightly different, since there is no response to that 
message. The Boot message is simply sent in both formats, with the 802 format frame sent 
first. 

Note that requests that are not expressible in Ethernet format, such as a Request Program 
message specifying a request for a CMIP Script, are sent in 802 format only. 

In MOP V3, the Verification field of the boot message was defined as being either 4 or 8 
bytes long. V4 implementations may send V3 format boot messages with 8 byte verification 
fields independent of the value in the field. However, MOP implementations receiving a boot 
message in V3 format must be prepared for a 4 byte or an 8 byte verification field. If a 4 byte 
verification field is received, the omitted 4 bytes are treated as zero. 

The Verification attribute in the Client database is an Octet String. In Phase IV, it was de- 
fined as a "Hex Integer", which is not a defined data type in CMIP. Since strings are written 
with the lowest numbered byte on the left, and integers with the lowest numbered byte on the 
right, this means that the same verification string is represented differently in the two manage- 
ment user interfaces. For example, the verification string written in this version of MOP as 
%x01 0256041 5A69708 would appear in the Phase IV management interface as 
0897A61 504560201 , or (omitting leading zeroes) as 897A6 1504560201 . This difference does not 
affect the protocol, but it does affect documentation. If a Boot target allows setting of the verifi- 
cation string in Phase IV format, but the Load Server implements MOP V4, the verification 
strings supplied in the user interface have to be bytewise reversed. 

G.3 Version handling on point to point data links 

The Request Program and Request Dump Service contain a "Format Version" field which in- 
dicates the version of the MOP architecture to which the requesting system conforms. The 
rules for the handling of this version number are as follows: 

• If the version number is higher than the highest version known to the Dump/Load 
server, ignore the request. 

• Otherwise, process the request according to the rules for the specified version. 



G.4: Request Program message 
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Note that the usual third case in version number handling does not occur here, 
since the only version number other than the one currently used (4) is 1 , which 
is used by all versions of MOP preceding V4.0.0. 

G.4 Request Program message 

The Program Type value of CMIP Script file can only be specified in a V4 format Request 
Program message. 

The rules given below for interpretation of the Data Link Buffer Size field in the System ID 
message (Appendix G.6) apply also to the interpretation of that field in the V3 format Request 
Program message. 

G.5 Parameter Load with Transfer Address message 

This message has changed substantially between MOP V3 and V4. Parameter type codes 1 
through 5 were defined in previous versions of MOP; parameter type code 6 is used only in V4. 
The values of parameters 1 through 4 are obtained from the Client database entry used for the 
Load operation. The characteristics used for each parameter are as follows: 



In the V3 format message, Host System Time is passed as parameter code 5, in the format 
specified in the V3 architecture specification. In the V4 format message, it is in addition passed 
as parameter code 6, as a Binary Absolute Time. 

The MOP V3 architecture defines parameters 2 and 4 as 6-byte values, though it leaves open 
the issue of whether shorter values are permitted. All known implementations in fact send only 
two bytes, exactly as in MOP V2.1. Therefore, V4 implementations must likewise send two 
bytes. The parameter value sent is the value of the Phase IV Client Address or Phase IV Host 
Address attributes, respectively. The low order byte of the attribute is sent first. 

A MOP V4 load client being loaded by a V3 load server will receive a Parameter Load mes- 
sage in V3 format. It uses parameter code 5 to obtain the local time of the load server, but that 
does not provide all of the information of the V4 format Host System Time field. Alternatively, 
the load client can implement the Time Service client, ignore the Host System Time field alto- 
gether, and instead use information obtained from the Time Service. (This is the preferable so- 
lution if the Time Service is available.) 

G.6 System ID message 

When sending a System ID message in V3 format, V4 nodes must omit those fields which are 
defined only in MOP V4 (Node ID, System Time, Node Name part 1 and 2, Station ID). System 
Time may be sent instead (if desired) using type code 8, encoded according to the V3 architec- 
ture specification. The Maintenance Version field is always sent with the value 4.0.0, indicat- 
ing a Version 4 MOP implementation, whether the System ID message is sent in Ethernet for- 
mat (to a V3 node) or in 802 format (to a V4 node). 



Parameter 



Attribute 

Phase IV Client Name 
Phase IV Client Address 
Phase IV Host Name 
Phase IV Host Address 



1 

2 
3 
4 
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In both the V3 and the V4 format messages, the value for Data Link Buffer Size specifies 
only the length of the MOP data (including MOP protocol header) but not any part of the 
Ethernet or IEEE 802.2 LLC header. Thus the largest possible value for V3 format messages 
on Ethernet is 1498; for 802.2 format messages on Ethernet the limit is 1492. 

Note: 

For compatibility with certain existing implementations, any value greater than 
1498 for Data Link Buffer Size when received in a V3 format System ID, Re- 
quest Program, or Request Dump Service message shall be interpreted as 1498. 
Furthermore, the value 1030 shall be interpreted as 1010. 

G.7 Counters message 

The MOP V4 CSMA/CD Counters message contains the list of counters specified in Appendix 
B.4. The V3 Counters message is substantially different: the counters are shorter, several 
counters are combined into a single counter with a "reasons" bitmap, Collision Detect Check 
Failure is omitted, and the time since counter initialization is encoded differently. Apart from 
the frame format, these two cases can also be distinguished by the length of the received 
counter block. 

For data links other than CSMA/CD (currently only FDDI) the counter block defined in MOP 
V3, or its modified form for V4 described above, is not suitable, since the set of counters are 
different for the different data links. Such data links therefore use a different message to re- 
spond to the Request Counters message, with message code 21. That message is new in MOP 
V4. Since it has no MOP V3 equivalent, non-CSMA/CD data links do not respond to the Re- 
quest Counters message from MOP V3 nodes. The System ID message sent on these data links 
reflects this rule: the V4 format System ID (sent in 802.2 format) will show Data Link Counters 
among the supported functions, but the V3 format System ID (sent in Ethernet format) does 
not. 
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Broadcast: 



As applied to data links, broadcast capability refers to the ability of any 
one node (link) to address all other nodes (links) simultaneously. 



Broadcast Address: 



This is a group address which is a distinguished, predefined multicast 
address that always denotes the set of all nodes on a given Extended 
LAN. The Broadcast Address is predefined to be the address with 48 
bit of all l's. 



CMIP Script: 



An description of the information required to initialize a node, encoded 
in the form of a sequence of network management directives in CMIP 
form. (See also "Management Image".) 



Datagram: 



An atomic unit of information exchanged by local area networks. 



Flow Control: 



A set of rules applied to processes, beetween the nodes , which prevents 
a transmitting process from sending data to a receiving process that is 
not prepared to buffer the transmitted data. 



Extended LAN: 



Diverse Local Area Networks interconnected, by the connecting 
network component called the Bridge, into an extended, logically 
integrated network. 



Disjoint Extended LAN: A disjoint Extended LAN is defined to be separate universes where 
under no condition shall the separate universes ever be merged 
together. 



Group Address: 



The first bit of the 48 bit address contains a 1, the first bit transmitted. 
This is a multi-destination address, associated with one or more 
stations on the Extended LAN. There are two kinds of Group address: 
Multicast address and Broadcast address. 



Hardware Address: 



This is the default hardware 48 bit LAN Address. This is the 
universally unique hardware address which may or may not be used as 
the physical (link) address. 



Individual Address: 



The first bit of the 48 bit address contains a 0, the first bit transmitted. 
All Physical (Link) addresses and Hardware addresses must be 
individual address. 
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LLC: Logical Link Control. The top sublayer of the data link that provides 

the mechanism to support multiplexing and demultiplexing of 
datagrams over the Medium Access Control sublayer defined by IEEE 
802.2 spec. 

MAC: Medium Access Control. The bottom sublayer of the data link that 

provides frame encapsulation/decapsulation, error checking and access 
control algorithms for controlling the sharing of the physical layer by 
the attached stations (nodes). 

Management image: A load image containing initialization data for a node, encoded in a 
product-specific manner. (See also "CMIP Script".) 

Multicast: As applied to data links, multicast capability refers to the ability of any 

one node (link) to address a subset of all other nodes (links), within the 
logical group, with a single datagram. 

Multicast Address: This is a Group Address as defined above. This is an address associated 
by higher-level convention with a group of logically related nodes. 

Physical (Link) Address: This is the 48 bit address that identifies the link's attachment point in 
the Extended LAN. This is the address recognized as specific 
destination in received frames and sent as source address in the 
transmitted frames. 

SAP: Service Access Point. The LLC header contains the address fields 

(DSAP, SSAP), which is the ordered pair of service access point 
addresses at the beginning of an LLC frame which identifies the LLCs 
designated to receive the frame and the LLC sending the frame. Each 
of the DSAP and SSAP is one octet in length. 



SNAP SAP: 



It is the Sub-Network Access Protocol (SNAP). 
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Load/Dump Service Implementation Notes 



This appendix contains a number of notes and suggestions for implementers of Load/Dump 
Clients and Servers. 



1.1 Downline load and upline dump over multi-mode point to point lines 

When load or dump service is to be provided via point to point lines (DDCMP or HDLC) it is 
sometimes necessary to provide the data link layer with operating parameters such as bit rate, 
framing mode, etc. For servers, this is in general not an issue because these parameters are set 
as part of the normal initialization procedure for the node. 

Clients may have difficulty providing these data link parameters, since clients run in primi- 
tive state. It is generally not convenient or even desirable to have to set up line parameters 
prior to downline load, for reasons such as: 

• Autoconfiguration: there should be no need for management setup as part of installa- 
tion ("Plug and Play"). 

• Lack of a local console: load clients often do not have any local management interface. 

For these reasons, a procedure similar to the "autobaud" mechanism used in many timeshar- 
ing systems would be desirable. Ideally, the autoconfiguration process should be able to deal 
with all of the following parameters: 

• Data Link protocol: HDLC vs. DDCMP, for lines that are capable of supporting both. 

• Byte framing mode: synchronous or asynchronous. 

• Line speed, for asynchronous framing mode. 

Such an autoconfiguration is feasible, provided that certain requirements are met at the 
server end. The server must have its parameters set up via management (i.e., it must not at- 
tempt to run the autoconfiguration procedure at the same time as the client), its data link must 
be On, and the data link must then run its data link initialization procedure indefinitely, rather 
than giving up after a limited number of retries. 

Given that the above requirements are met, a simple client algorithm that meets the above 
goals is as follows: 
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1. Set the framing mode for the data link to Synchronous. Generally this also requires 
setting the data link for externally supplied bit clocking (e.g., from the modem). Set the 
data link protocol to HDLC (bit stuffing mode) and attempt to receive some frames. 

If the server is indeed using HDLC, valid frames will be received within a few seconds, 
containing HDLC data link startup messages (SABM, SABME, or XID). 

2. Set the data link protocol to DDCMP (byte count character oriented) and attempt to re- 
ceive some frames. If the server is running DDCMP in synchronous mode, valid frames 
will be received within a few seconds, containing DDCMP data link startup messages 
(ISTRT). If the server is trying to perform MOP protocol operations on the data link, 
MOP mode DDCMP messages will be received instead. 

3. Set the framing mode for the data link to Asynchronous. For each of the data link 
speeds to be supported, set the data link to that speed and listen for a few seconds for 
messages as above. Examine the messages to see if they are valid HDLC or DDCMP 
initialization messages. If none are heard, proceed to the next speed. 

This algorithm can be repeated until it completes. 

1.2 Downline load and upline dump service on diskless servers 

When load or dump clients have multiple circuits, it is generally required that any of the 
lines can be used for downline load or upline dump. This may appear difficult when some of 
these lines are point to point lines connected to neighbors that have no disk storage, such as 
routers. This section presents a way to provide load/dump service in such cases. 

MOP does not require that the load server have local file storage, such as disks. It may use 
any available means to obtain the files. In particular, remote file access protocols, such as DAP, 
may be used. DAP is well suited to this job, since the subset required by load servers is quite 
small. Only sequential read access is needed, and block mode can be used. This means that the 
DAP access amounts to little more than establishment of the Transport connection to the file 
server and receiving of the data blocks over that connection. Similarly, for upline dump only 
sequential write access is needed, and again block mode is sufficient. 

Diskless load servers still include a normal MOP Load Server module, with the usual man- 
agement interface. The necessary attributes, in particular the Client database, can be set up in 
any convenient manner, for example with the initialization script. The client database would 
contain the necessary entries to describe the requests the server must deal with. One of these 
would be an entry for the neighbor on the point to point line. The various attributes in the cli- 
ent database that specify the load file names are set to point to the files on the file server that 
stores the load files. These attributes are Sequence of FileSpec to allow the network manager 
to specify multiple locations for the files. This provides for redundant file servers. 

1.3 Downline load and upline dump in clients with multiple data links 

The algorithms given in the Operation chapter (Chapter 4) are for a load or dump operation 
on a single data link circuit. If the client has multiple circuits, the load or dump should be able 
to use any of them. The client needs some way to select the circuit on which the operation can 
be completed. Once it has done this, the remainder of the load or dump operation is executed in 
the usual manner. 

There are several ways the initial step of the load or dump can be done on a multi link client. 
The most efficient way is to send the first message (Request Program in the case of downline 
load, Request Dump Service in the case of upline dump) simultaneously on each of the circuits. 



1.3: Downline load and upline dump in clients with multiple data links 
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When a response is received on any of the circuits, that circuit is selected, and the rest of the 
operation proceeds as usual on that circuilt. 

The advantage of this "parallel" approach is speed and the fact that it requires no additional 
state to be kept, but it does require dealing with multiple circuits simultaneously. 

Alternatively, the client can attempt to initiate the operation on the circuits one at a time in 
"round robin" fashion. To do this, the client would send the first message of the operation on 
one of the circuits, performing a small number of retries (4 retries would be suitable). If no re- 
sponse is received, the same is then done for the next circuit, and so on through each of the 
available circuits. 

The "round robin" approach is potentially slower, but it may be easier in some implementa- 
tions. All circuits except the one being tried at any point in time are logically Off, so the client 
does not need to do any processing for the other circuits. (Note in particular that the require- 
ments of the Node Product Architecture apply only to data links that are On — in this case, 
only one data link circuit is On at any time.) 
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